Does anyone know of any examples of compilers for flat memory
architectures in which uintptr_t is defined, but the underlying values
aren't just the memory addresses you'd use in the machine code for the
architecture?

fabricated e.g., "The cccccc compiler for the DMR-VI machine has
uintptr_t with all bits reversed!"

Thanks,
--Anthony

Anthony Cuozzo <anthony@cuozzo.us> writes:
>Does anyone know of any examples of compilers for flat memory
>architectures in which uintptr_t is defined, but the underlying values
>aren't just the memory addresses you'd use in the machine code for the
>architecture?

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Anthony Cuozzo <anthony@cuozzo.us> writes:
> Does anyone know of any examples of compilers for flat memory
> architectures in which uintptr_t is defined, but the underlying values
> aren't just the memory addresses you'd use in the machine code for the
> architecture?
>
> fabricated e.g., "The cccccc compiler for the DMR-VI machine has
> uintptr_t with all bits reversed!"

No, but I have an interesting counterexample.

Cray vector machines (T90, SV1, etc.) have 64-bit words, and
machine-level addresses are 64-bit words that can only address a full
word. There is no hardware support for addressing octets. The C
implementation has CHAR_BIT==8, so byte addresses are constructed in
compiler-generated code by storing a 3-bit byte offset in the high-order
3 bits of a pointer value. The maximum address space is far smaller
than 64 bits, so it's not necessary to make char* and void* bigger than
int*; those bits would always have been zero. One consequence of this
is that string-handling code is relatively slow. These machines are
heavily optimized for floating-point computations.

Casting between a pointer and a 64-bit integer, for example uintptr_t,
just copies the bits of the representation.

I once fixed some code that was trying to do pointer arithmetic by
converting to an integer and doing arithmetic on the result, which would
give garbage results if the 3-bit offset is non-zero, and results off by
a factor of 8 even if the offset is zero. The fix was simply to do
pointer arithmetic, which the compiler takes care of getting right.

(The compiler *could* have implemented pointer-to-integer conversion by
constructing a byte address, but there would be no great advantage in
that other than catering to non-portable code -- and providing a
positive answer to your question.)

And to be clear, the issue is not how uintptr_t is represented.
uintptr_t itself is just an alias for an existing unsigned integer type
(possibly an extended integer type, but very probably just one of the
predefined ones). The issue is whether a conversion from a pointer to a
same-sized integer does something more than blindly copying the bits.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */