This is the mail archive of the 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]
Other format: [Raw text]

Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?

Andrew Haley wrote:
This doesn't sound very different from the small memory model.  With
the small model, the program and its symbols must be linked in the
lower 2 GB of the address space, but pointers are still 64 bits.  This
is the default model for gcc on GNU/Linux.  It would be possible in
theory to have a `smaller' memory model that only allowed 32-bit
pointers, I suppose.

Small memory model ? I don't understand the point of the "small memory model" nor can I substantiate anything you are saying from the littlepickcloud, LOL what a domain.

I'm not aware of a small memory model until now, let alone that I maybe actually using it already and that its already what I'm making an inquiry about.

I wonder if you are aware of the differences between SPARC V8 and V8+ ABIs, how they are both 32bit runtime memory model, using 32bit pointers, but the V8+ only works on a 64bit capable CPU and on a kernel that supports both 32 and 64bit userspace and is itself 64bit internally ?

Yes maybe there is a restriction in the ELF format on the maximum executable size but linking has little to do with the issue of improving performance via better linkage ABI rules. Passing function arguments by registers [64bit] verses by stack [32bit].

The problem was not that I need to create a final executable file near the 2Gb limit but one of what benefits can be got from newer 64bit capable IA32 cpus from the extra registers available being used to run 32bit code running in a 32bit address space.

One of the issues is that pointer storage is 8 bytes, so all structure sizes increased, so more memory is needed. So pointer intensive applications have poor memory footprints as 64bit application and most desktop applications do not require more than 3Gb of exec+heap+stacks+etc.

I also believe code size will reduce too, due to less code needed to manage passing arguments via the stack and better code generation.

This is amazing!  There is no way that going from the ia32 to
(presumably) the x86_64 small model should more than double memory
consumption.  Where has all that memory gone?  I think some analysis
of memory consumption is needed.

I presume all the memory is eaten up dealing with 64bit issues both Mozilla (using XPCom) and Eclipse (running in a Java JVM) make extensive use of pointers. Although Mozilla is a little harder for me to measure comparatively but I've never gotten it over 1Gb Resident Set Size (with no swap in use).


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