On 12/5/07, Jan Beulich <[EMAIL PROTECTED]> wrote:
> >>> "Andrew Pinski" <[EMAIL PROTECTED]> 25.11.07 19:45 >>>
> >On 11/25/07, Luca <[EMAIL PROTECTED]> wrote:
> >> 7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
> >> to allow 64-bit pointers in 32-bit mode and viceversa
> >
>
>>> "Andrew Pinski" <[EMAIL PROTECTED]> 25.11.07 19:45 >>>
>On 11/25/07, Luca <[EMAIL PROTECTED]> wrote:
>> 7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
>> to allow 64-bit pointers in 32-bit mode and viceversa
>
>This is already there, try using __attribute__((mode(DI) )).
>>You can't use conventional 32-bit x86 code, so there seems little or no
>>benefit in allowing 32 and 64-bit code to be mixed.
>
>Why not? Switching between 32- and 64-bit modes doesn't involve anything
>(apart from knowing the proper selector register values) that cannot be done
>purely in user
>You can't use conventional 32-bit x86 code, so there seems little or no
>benefit in allowing 32 and 64-bit code to be mixed.
Why not? Switching between 32- and 64-bit modes doesn't involve anything
(apart from knowing the proper selector register values) that cannot be done
purely in user mode.
On 11/25/07, Luca <[EMAIL PROTECTED]> wrote:
> 7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
> to allow 64-bit pointers in 32-bit mode and viceversa
This is already there, try using __attribute__((mode(DI) )).
-- Pinski
> 7. Add support for loading x86-32 and x86-64 objects in the same
> address space, using a single modified 64-bit libc.
I'm not convinvinced this is practical, or even possible. I'd expect the
restrictions imposed on code to make it work properly to be too onerous for
it to be of any real use.
This proof of concept patch modifies GCC to have 32-bit pointers and
longs on x86-64.
This allows to create an "x86-32" architecture that takes advantage of
the higher number of registers and support for 64-bit computation in
x86-64 long mode while avoiding the disadvantage of increased memory
usa
