This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: __LP64__ defined on Alpha Linux?



> "P64", actually.

that makes sense and now that you mention it, I recall seeing it:)

> I'm not planning on adding a 32-bit object model.
>
> It's been on some folks wish lists, and I don't know of anyone else
> planning to do it either.  When one starts to consider parallel sets
> of runtime libraries, one starts to blanch.

Not counting the develpment load, that second set of libraries doubles ones
system test and regression load, although that isn't well defined for libc
and the kernel.

For products like DB2, which I work on, we don't have a choice, since we
have pre-existing customers using 32 bit (not talking about alpha here).
If we didn't we would probably go 64 bit only on any platforms that
supported it since for us 64 bit nicely removes piles of platform limits.

This is not just the obvious 4Gb VM limit (so you can create large
bufferpools and utilize memory if it is there), but other things like
handling stack/heap collisions, and the number of mappable shared memory
segments.  These are both examples of 32 bit limits on AIX, since the stack
and heap both share segment 2 for 32 bit (256M max), and the number of
total shared memory segments has a hard limit of less than 16 (unless a
special environment variable is used on versions of AIX that support it).
I am sure other non-AIX systems have similar limits that just aren't issues
on 64 bit.  HP comes to mind as well due to its 4 quad memory segmentation,
but HP doesn't count too much since everything sucks on that platform ;)

Peeter



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]