* H. J. Lu: > On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer <f...@deneb.enyo.de> wrote: >> * H. J. Lu: >> >>>> Actually, I'm wondering if you can do the translation in user space. >>>> There already are 32-on-64 implementations in existence, without >>>> kernel changes (recent Hotspot, LuaJIT, and probably some more). >>> >>> Please check out the x32 kernel source and provide feedback. >> >> I still don't understand why you need a separate syscall table. You >> should really be able to run on an unmodified amd64 kernel, in 64 bit > > That is done on purpose. x32 is designed for environments where the > current ia32 API is sufficient. You can think it as ia32 with register > extended to 64bit plus 8 more registers. Everything else is still 32bit.
I think of it as amd64 where all the process memory happens to reside in the first 4 GB of address space, and pointers are stored as 32 bits (and you'd also reduce the size of longs because sizeof(long) != sizeof(void *) will break too many programs). As I said, both LuaJIT and Hotspot are already using this model, with custom memory allocators and a user-space translation layers, so I still don't see what you get by changing the kernel. LuaJIT has even implemented the amd64 ABI, so you can call C libraries from your 32-bit code. (Note that LuaJIT uses 64-bit words to store 32-bit pointers with several tag bits, but it does so even on pure 32-bit platforms.) If you want to make x32 closer to i386, I don't see the point. Why would it be problematic if it was as close to i386 as, say, armel?
