lkml.org 
[lkml]   [2011]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: X32 psABI status
Date
* H. J. Lu:

> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer <fw@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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-02-13 16:25    [W:0.055 / U:0.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site