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

[Darryl Miles <darryl-mailinglists at netbauds dot net>]

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).



Darryl