Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Paul Brook]

> With proper support from the compiler, it's theoretically possible on
> x86-64 systems to use 32-bit pointers in long mode. I'm not aware of any 
systems that use this, however.

Vxworks does. We just finished doing the gcc port. From a software point of 
view ILP32 mode on a 64-bit CPU/OS is indistinguishable from regular 32-bit 
mode.
>  I'm not sure how big longs are on those systems, but I
> wouldn't be surprised if longs are 32-bits or 64-bits and pointers
> 128-bits.

I really hope not.

> > > One from me, if you like... Just don't use the "unsigned long" type.
> > > The intptr_t type would be better (it's 32-bit on 32-bit systems and
> > > 64-bit on 64-bit systems).
> >
> > Nice, I didn't know about that. But how is this any different from
> > unsigned long?

The story behind this is that ISO C89 requires that "long" be at least as big 
as a pointer (ie. "void *"). The actual requirement is that it be possible to 
store a pointer in a standard integer type, and "long" is the largest 
standard integer type.

Unfortunately C99 relaxed this requirement, and allowed abominations like the 
win64 ABI.

This means you have a choice: Write standard conforming code (long) that works 
on all known systems except win64, or use features that do't exist on many 
systems. IIRC C99 types like intptr_t are not supported on several fairly 
common unix systems.

It's ironic that the one system that requires C99 features explicitly does not 
(and probably never will) have full C99 support.

Paul