Re: RFC: Adding minimal amd64/biarch support for sarge
Peter Cordes <email@example.com> 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
>> > 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.