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

[Karl Magdsick]

Depends on if you're using the LP64 model (64-bit Linux, many other
*NIX) or the LLP64 model (Win64).

I guess Microsoft decided there was more code written for their system
that assumed longs were 32-bit than code that assumed pointers could
be stored in (unsigned) longs.  For 64-bit  MS Windows code, pointers
are 64-bit, longs are 32-bit, and long longs are 64-bit.

With proper support from the compiler, it's theoretically possible on
x86-64 systems to use 32-bit pointers in long mode (16 general purpose
64-bit registers).  (There's an instruction prefix that will cause the
CPU to perform 32-bit pointer calculations in the 64-bit address
space.) I'm not aware of any systems that use this, however.  (Getting
the speed boost from fewer register spills while not paying the space
cost of 64-bit pointers sounds very attractive in many applications,
though.)  I'm not sure if any of the C standards forbid longs being
larger than pointers.

There are even more strange beasts out there.  I think IBM AS/400 LIC
uses 128-bit pointers.  (The LIC code gets compiled to native code and
appended to the LIC binary the first time the LIC binary is run on a
new system, and IBM decided to build a lot of future compatibility
into LIC.)  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.

In any case, I'm a big fan of using more descriptive types (such as
the C99 types) to express yourself more clearly for both the compiler
and for other coders.


Cheers,
-Karl

On 6/25/07, Blue Swirl <address@hidden> wrote:
> On 6/25/07, Michal Schulz <address@hidden> wrote:
[snip]
> > 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?