Peter Cordes <[EMAIL PROTECTED]> writes: > On Thu, Aug 05, 2004 at 02:29:12PM +0200, Goswin von Brederlow wrote: >> It won't use the extra registers in 32bit mode. > > Yeah, I know there's no CPU mode that does that. I wish, though... > >> It would be >> theoretically possible to build for 64bit (with extra registers) but >> 32bit pointers [The Tru64 cc can do that on alpha] but it would >> require extending the pointers to 64bit on every use and would >> probably void all the speedup. > > Yeah. What if you mmap a memory pool below 2GB in virtual address space, > so you only have to zero-extend? Isn't that what AMD64 does when you do a > 32bit move from memory to register? gcc -mcmodel=small still uses 64bit > pointers though, because it doesn't constrain data to be in the low 2GB.
You can use -2GB - 2GB and sign extend or 0 - 4GB and 0 extend. Depends on what the cpu supports. >> One thing you could do with gcc to emulate this is to use an array >> index instead of a pointer. > > That's a thought. There are lots of ways to store trees, and data > structures with 64bit pointers could be avoided to cut down on cache > traffic. > >> > So, for me (and my ~dozen users) at least, this really would be useful. >> > If >> > you can't get it into sarge, I don't mind tracking unstable for some >> > packages on the cluster (it's not quite what some would call a "production" >> > system). It would rock to have it in sarge :) >> >> The progress looks good. I have made an amd64-libs package with some >> patches from Daniel Jacobowitz and he has made a gcc-3.4 package. Now >> if I get thekernel-image-amd64 build and all of them through new in >> time you have the 32/64 bit support. > > Your work (and all amd64 porters') is much appreciated. happy hacking :) Amd64-libs is in queue/NEW. gcc-3.4 and kernel-image-amd64 are ready for deployment. The plan is to upload gcc-3.4 to sid once amd64-libs clears NEW and to t-p-u once it enters sarge (if the maintainer and RM agree). The kernel image would follow close behind. MfG Goswin