Comment 8 for bug 185263

On Mon, May 5, 2008 at 6:46 AM, Adam Buchbinder
<email address hidden> wrote:
> If it's an upstream problem (as Tollef said, "Not only would you need a
>
> different libc, you would have to have _all_ other libraries compiled
> with this same other ABI. I suspect you would have to get support into
> the kernel as well for it."), where's the best place to start filing
> wishlist bugs for it? The gcc bugzilla? The glibc bugzilla? The kernel
> bugzilla? Is this entirely impossible without hardware support from
> Intel and AMD? (Given that the request is simply for the option to
> compile some applications to use 32-bit pointers and be restricted to
> 4GB of address space, perhaps the problem can be solved at the virtual
> memory level rather than requiring specialized hardware?)

Well, let's think this through for a sec. The goal is to have 32-bit
pointers to better use processor cache, but still use the enhanced
instructions and registers provided by the amd64 instructions. This
is off the top of my head without doing any research at all. That
means I've likely missed at least one step in here.

This is probably possible on the hardware, although I haven't looked
at it directly. Assuming it is:

You first need to define an ABI document describing what registers and
such would be used for calling conventions.

You then need to talk to the toolchain folks to get a GNU triple
assigned to this mode.

The kernel would have to be hacked to setup the address space
appropriately (make sure that the vDSO and such were located in low
enough memory).

Binutils would need hacking to understand that triple, and maybe some
tweaks to the assembler to check for invalid pointer sizes, and some
tweaks to the linker.

gcc would need hacking to restrict itself to a 32bit address space,
while teaching it about the additional registers and instructions.

Then you'd need to hack on glibc to make sure that it knew the triple
and would build. This would also mean hacking any custom asm files so
that they constrained themselves appropriately. There would probably
be some elf changes as well to match the ABI document.

After all this had happened, you'd then need to convince some distro
that enough people would care about cache lines and wanted the
additional performance so that they'd go through the hassle of
building this and QAing, etc. You'd also have to hack on any
multimedia libraries and crypto libraries to provide the optimised
versions to get decent performance.

I have a vague feeling that we've heard from the only person who
*actually* cares about this problem. Anyone else is probably using
ppc+altivec, sparc or some other arch where the 32 bit environment in
closer to what the 64 bit one provides.

Tks,
Jeff Bailey

--
Jeff Bailey - http://www.raspberryginger.com/jbailey/
 - "Remember, homosexuality is a choice, like cancer" - midwestteensexshow.com