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 stand
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 cal
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 mean
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
> > > > 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.
> > >
> > > In th
Julian Seward wrote:
>
> > > 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 m
> > 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 in
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
> 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 ind
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 6
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
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
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 6/25/07, Michal Schulz <[EMAIL PROTECTED]> wrote:
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 B
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
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 som
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 still many
left.
Any co
17 matches
Mail list logo
