ilp32 far pointers

[David McQuillan]

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]