Re: ilp32 far pointers

[David McQuillan <dmcq at fano dot co dot uk>]

On 15/09/2013 16:46, Jonathan Wakely wrote:
> On 15 September 2013 14:58, David McQuillan wrote:
> > The basic aim of ilp32 is to emulate an old 32 bit environment on a new
> > processor that supports 64 registers and pointers. However that has 
> > never
> > been the real aim, if one was just trying to support old programs there
> > would be little need for a special compiler option as you'd have the old
> > compiler.
> >
> > The main impetus has been to use less space and get faster running 
> > programs.
> > There is no point having compatible syscalls with the 32 bit emulation
> > environment even if one is already supporting one for old programs if 
> > one
> > can run the new program in the 64 bit environment. That is just a 
> > route to
> > extra support costs when new features are brought in. The only real
> > requirements I can see for running in a 64 bit environment is that 
> > malloc
> > and suchlike should restrict the addresses and the 64 bit debugger 
> > should
> > understand 4 byte restricted addresses and ELF not reuse the same ids 
> > with
> > different lengths. The extra facility one would want in the 32 byte 
> > program
> > is that pointers get turned into 64 bit pointer automatically on system
> > calls and that even if system structures have 8 byte pointers in them 
> > only 4
> > bytes are loaded and this could be done by having some pointers, or 
> > maybe
> > instead whole structures and procedure declarations, marked as 64 bit 
> > type
> > (or longest supported type say).
> >
> > A more complete implementation than just ignoring the high part of the
> > addresses would be to actually distinguish between the two with warnings
> > when converting to 32 bit and to actually use the top part of a 64 bit
> > address even in an ilp32 environment, e.g. for access to a large memory
> > mapped file where one hadn't restricted it to the 32 bit address space.
> [Please don't top-post on these lists.]
>
> It's still not clear exactly what you want, but if you read about the
> x32 architecture you might be able to say whether that is or isn't
> what you want.
>
> x32 doesn't just "ignore the high part of addresses" because it's
> ILP32 so there is no high part to be ignored, pointers are 32-bit.

Yep I should read more, I'd been looking more at the MIPS business but 
x32 is more like what I should have looked at

https://lwn.net/Articles/456731/

actually describes most of what I had been thinking of in some of its 
comments and the relevant reply seems to be:

> (2) Use a compiler extension that does this transparently, i.e. that 
> supports a special pointer type where the high order bits are always 
> zero.
> ...
> (2) seems ideal, but requires cooperation for every supporting 
> compiler. I don't know exactly why, but the x32 ABI devs are trying to 
> avoid that if at all possible.

so basically it seems to me like there was probably a trade off between 
the compiler and the kernel and the work in the kernel was easier. I 
suppose that's fair enough and it isn't a killer.

Thanks

David

[and this time I forgot to set my message to text only and got it 
rejected first time, oh dear]