MPI_Count must be able to hold an absolute address

[jedbrown]

Problem

MPI 4.0 section 2.5.8 Counts says

Even though the MPI_Count type is large enough to encode address locations, the MPI_Count type shall not be used to represent an absolute address.

This isn't true because MPI_Type_create_struct_c takes displacements as an MPI_Count and can be used with MPI_BOTTOM, thus displacements are absolute addresses. Specifically for CHERI architectures (where MPI_Aint will be 128b), MPI_Count must also hold the special bits.

Proposal

We have two choices

1. strike the sentence
2. Replace with a correct clarifying sentence. Suggestion:

MPI_Count may be used to specify displacements with respect to MPI_BOTTOM, thus may store a pointer value.

Changes to the Text

Strike or replace this sentence.

Impact on Implementations

None; implementations already support this.

Impact on Users

Clarity reading the standard.

References and Pull Requests

[jedbrown]

Some further clarifications of terminology may be useful to articulate at some point with respect to CHERI where one could assume that "absolute address" refers to the 64b address part, not the whole 128b representation of a pointer (or intptr_t).

https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf

[jedbrown]

Cc: @jeffhammond

[jeffhammond]

I think one of the unfortunate aspects of the MPI standard is that the distinction between pointer and address seems informed primarily by what C does with segmented addressing because of x86 circa 1982, and hasn't been updated to reflect the more modern situation where pointers are wider than addresses.

My hope is that typedef intptr_t MPI_Aint from the ABI will simply at least some of this.

[VictorEijkhout]

On Aug 11, 2023, at 15:57, Jeff Hammond ***@***.***> wrote: pointers are wider than addresses. I could use two words of clarification on this. Victor.

[jedbrown]

@VictorEijkhout See the CHERI figure and paper above #735 (comment).

[jeffhammond]

From 5.1.1 Type Constructors with Explicit Addresses:

For the large count versions of three datatype constructors with explicit addresses, MPI_TYPE_CREATE_HINDEXED, MPI_TYPE_CREATE_HINDEXED_BLOCK, and MPI_TYPE_CREATE_STRUCT, absolute addresses shall not be used to specify byte displacements since the parameter is of type MPI_COUNT instead of type MPI_AINT.

The standard is self-consistent, at least.

[jeffhammond]

I am trying to figure out why we did this in the first place. I don't remember, but I wonder if it's something to related to zero-extend versus sign-extend when one has a address that requires the upper half of a N-bit MPI_Aint and MPI_Count is 2N-bit, or a related challenge associated with C's rules on arithmetic with unsigned and signed integer types. I haven't come up with the right pathological example yet, but I suspect there is one that reveals why we can't solve this without defining the MPI integers.