Date: Wed, 05 Jul 2023 18:08:34 -0700
On Wednesday, 5 July 2023 16:46:50 PDT Brian Bi via Std-Discussion wrote:
> For the reasons above, such a requirement would not be well-defined, and
> therefore, does not exist in the standard.
The simplest case where this would apply is when your pointer needs fewer bits
than the smallest integer that can fit it will provide. For example, think of a
machine with 48 bit pointers, but with regularly-sized integers. Your
uintptr_t would likely be uint64_t, with 16 bits to spare. The implementation
could decide to store a pattern (a colour) in those bits to ensure you didn't
accidentally lose information by going through a 32-bit pointer. And it could
chose to do that in the low bits.
Another example would be the case of the segmented memory model that used to
exist on x86, but storing the segment or the descriptor selector in the low
word of the combined pointer instead of the high one. So for example a pointer
of 0x17:0x300 could end up as as uintptr_t(0x0300`0017). This is not what x86
did because the hardware actually imposed a memory layout with its FAR
instructions (lcall, ljmp, lret, and lds/les/lfs/lgs/lss).
To make this a near-reality, think of i386 with 48-bit segmented pointers. In
this machine, the FAR instructions would load 48 bits from memory, but
uintptr_t being uint64_t would have 16 bits to spare. This actually exists
today and you can write code that uses those instructions. But making this
more interesting, imagine that i386 had been big-endian (I'm told by
colleagues that this feature did exist in a prototype when Intel was courting
some of the big-endian Unix vendors). In that case, those FAR instructions
loading 48 bits in a 64-bit memory block would load the high 48 bits and
ignore the low 16, so it's entirely plausible for an implementation to store a
pattern in those low bits in debug mode.
PPS: 64-bit x86 still retains most of those FAR instructions, now using 80-bit
pointers. Not even the x86-S proposal[1] that removes most of the legacy is
proposing to remove those.
[1] https://www.intel.com/content/www/us/en/developer/articles/technical/
envisioning-future-simplified-architecture.html
> For the reasons above, such a requirement would not be well-defined, and
> therefore, does not exist in the standard.
The simplest case where this would apply is when your pointer needs fewer bits
than the smallest integer that can fit it will provide. For example, think of a
machine with 48 bit pointers, but with regularly-sized integers. Your
uintptr_t would likely be uint64_t, with 16 bits to spare. The implementation
could decide to store a pattern (a colour) in those bits to ensure you didn't
accidentally lose information by going through a 32-bit pointer. And it could
chose to do that in the low bits.
Another example would be the case of the segmented memory model that used to
exist on x86, but storing the segment or the descriptor selector in the low
word of the combined pointer instead of the high one. So for example a pointer
of 0x17:0x300 could end up as as uintptr_t(0x0300`0017). This is not what x86
did because the hardware actually imposed a memory layout with its FAR
instructions (lcall, ljmp, lret, and lds/les/lfs/lgs/lss).
To make this a near-reality, think of i386 with 48-bit segmented pointers. In
this machine, the FAR instructions would load 48 bits from memory, but
uintptr_t being uint64_t would have 16 bits to spare. This actually exists
today and you can write code that uses those instructions. But making this
more interesting, imagine that i386 had been big-endian (I'm told by
colleagues that this feature did exist in a prototype when Intel was courting
some of the big-endian Unix vendors). In that case, those FAR instructions
loading 48 bits in a 64-bit memory block would load the high 48 bits and
ignore the low 16, so it's entirely plausible for an implementation to store a
pattern in those low bits in debug mode.
PPS: 64-bit x86 still retains most of those FAR instructions, now using 80-bit
pointers. Not even the x86-S proposal[1] that removes most of the legacy is
proposing to remove those.
[1] https://www.intel.com/content/www/us/en/developer/articles/technical/
envisioning-future-simplified-architecture.html
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-07-06 01:08:36