On Wednesday 27 June 2007 06:26:54 Blue Swirl wrote:
On 6/26/07, Paul Brook [EMAIL PROTECTED] wrote:
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
Hi,
2007/6/26, Karl Magdsick [EMAIL PROTECTED]:
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
On 6/26/07, Paul Brook [EMAIL PROTECTED] wrote:
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
On Wed, 27 Jun 2007, Julian Seward wrote:
In Valgrind-world we use an alternative approach, which is to typedef
a set of new integral types and use those exclusively, and not use the
native 'int', 'long' etc. The new types have a single fixed meaning
regardless of the host or guest
Marius Groeger wrote:
On Wed, 27 Jun 2007, Julian Seward wrote:
In Valgrind-world we use an alternative approach, which is to typedef
a set of new integral types and use those exclusively, and not use the
native 'int', 'long' etc. The new types have a single fixed meaning
Karl Magdsick wrote:
[snip]
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
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
On Monday 25 June 2007, Blue Swirl wrote:
This patch removes the restriction of 2G ram size on 64-bit hosts.
Theoretically Sparc32 on a SS-10 like machine could handle more than
62GB of memory.
There seems to be problems in the boot BIOSes to manage even 2G
memory sizes, I've found some in
Blue Swirl wrote:
This patch removes the restriction of 2G ram size on 64-bit hosts.
Theoretically Sparc32 on a SS-10 like machine could handle more than
62GB of memory.
There seems to be problems in the boot BIOSes to manage even 2G
memory sizes, I've found some in OpenBIOS but there are
On 6/25/07, Thiemo Seufer [EMAIL PROTECTED] wrote:
Blue Swirl wrote:
This patch removes the restriction of 2G ram size on 64-bit hosts.
Theoretically Sparc32 on a SS-10 like machine could handle more than
62GB of memory.
There seems to be problems in the boot BIOSes to manage even 2G
On Monday 25 June 2007, Blue Swirl wrote:
Nice, I didn't know about that. But how is this any different from
unsigned long?
It may be the same. But at least the code looks more consistent (IMHO) :)
--
Michal Schulz
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
13 matches
Mail list logo
