Integer subtype and NaN trick

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Integer subtype and NaN trick

Dirk Laurie-2
It is not spelt out in the slides of Roberto's 2012 presentation,
but it seems obvious that the proposed integer subtype will
from the point of view of the NaN trick look like a non-number:
the real 64-bit value will have to be stored elsewhere.

Reply | Threaded
Open this post in threaded view
|

Re: Integer subtype and NaN trick

Roberto Ierusalimschy
> It is not spelt out in the slides of Roberto's 2012 presentation,
> but it seems obvious that the proposed integer subtype will
> from the point of view of the NaN trick look like a non-number:
> the real 64-bit value will have to be stored elsewhere.

It will not use the NaN trick. (The trick does not work anyway in 64-bit
machines.) The real 64-bit value will be stored in the same 64 bits that
a double (or a pointer) is stored.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Integer subtype and NaN trick

Miles Bader-2
Roberto Ierusalimschy <[hidden email]> writes:
> It will not use the NaN trick. (The trick does not work anyway in 64-bit
> machines.)

I think the NaN trick *could* work in 64-bit machines...

http://lua-users.org/lists/lua-l/2011-07/msg00172.html

-miles

--
x
y
Z!

Reply | Threaded
Open this post in threaded view
|

Re: Integer subtype and NaN trick

Coda Highland
On Sat, Jun 15, 2013 at 6:11 PM, Miles Bader <[hidden email]> wrote:
> Roberto Ierusalimschy <[hidden email]> writes:
>> It will not use the NaN trick. (The trick does not work anyway in 64-bit
>> machines.)
>
> I think the NaN trick *could* work in 64-bit machines...
>
> http://lua-users.org/lists/lua-l/2011-07/msg00172.html
>
> -miles

The problem is that on modern OSes, you can't assume that you can fit
a 64-bit pointer in 48 bits. This is (part of) why LuaJIT demands to
use the low 2GB.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Integer subtype and NaN trick

Miles Bader-2
Coda Highland <[hidden email]> writes:
> The problem is that on modern OSes, you can't assume that you can
> fit a 64-bit pointer in 48 bits.

My impression was that current implementations of the x86-64
architecture only use 48 bits of addresses, requiring the upper 16
bits to be identical.  Has this changed with very recent
implementations?

> This is (part of) why LuaJIT demands to use the low 2GB.

Yeah the 2GB limitation is a huge lose... but that's obviously a lot
more restrictive than necessary...

-miles

--
Insurrection, n. An unsuccessful revolution.

Reply | Threaded
Open this post in threaded view
|

Re: Integer subtype and NaN trick

Coda Highland
On Sat, Jun 15, 2013 at 10:35 PM, Miles Bader <[hidden email]> wrote:
> Coda Highland <[hidden email]> writes:
>> The problem is that on modern OSes, you can't assume that you can
>> fit a 64-bit pointer in 48 bits.
>
> My impression was that current implementations of the x86-64
> architecture only use 48 bits of addresses, requiring the upper 16
> bits to be identical.  Has this changed with very recent
> implementations?

Unless I'm wrong, ASLR isn't restricted to 48 bits. Virtual memory
allocation can use whatever addresses it wants.

>> This is (part of) why LuaJIT demands to use the low 2GB.
>
> Yeah the 2GB limitation is a huge lose... but that's obviously a lot
> more restrictive than necessary...

Well, there are ways around it in LuaJIT.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Integer subtype and NaN trick

Owen Shepherd
Coda Highland wrote:

Unless I'm wrong, ASLR isn't restricted to 48 bits. Virtual memory
allocation can use whatever addresses it wants.


The hardware itself is physically limited to 48-bits.  Each page is 4kB, plus there are 4 layers of page tables, bringing the total up to 48 bits.

The processors throw an exception on a memory access if bits 63-48 don't match bit 47.

This is all baked into silicon
Reply | Threaded
Open this post in threaded view
|

Re: Integer subtype and NaN trick

Coda Highland
On Sun, Jun 16, 2013 at 12:14 AM, Owen Shepherd <[hidden email]> wrote:

> Coda Highland wrote:
>
>
> Unless I'm wrong, ASLR isn't restricted to 48 bits. Virtual memory
> allocation can use whatever addresses it wants.
>
>
>
> The hardware itself is physically limited to 48-bits.  Each page is 4kB,
> plus there are 4 layers of page tables, bringing the total up to 48 bits.
>
> The processors throw an exception on a memory access if bits 63-48 don't
> match bit 47.
>
> This is all baked into silicon

Oh, huh. TIL. Good to know.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Integer subtype and NaN trick

Jay Carlson
In reply to this post by Owen Shepherd
On Jun 16, 2013, at 3:14 AM, Owen Shepherd wrote:

> Coda Highland wrote:
>>
>> Unless I'm wrong, ASLR isn't restricted to 48 bits. Virtual memory
>> allocation can use whatever addresses it wants.
>
>
> The hardware itself is physically limited to 48-bits.  Each page is 4kB, plus there are 4 layers of page tables, bringing the total up to 48 bits.
>
> The processors throw an exception on a memory access if bits 63-48 don't match bit 47.
>
> This is all baked into silicon

Amusingly, 64-bit ARM is 49-bit. Twice as good as amd64!

64-bit ARM also has a mode which ignores the high 8 bits of addresses. Sadly, NaNs are still then in the high part of memory.

Jay
Reply | Threaded
Open this post in threaded view
|

Re: Integer subtype and NaN trick

Tim Hill
In reply to this post by Owen Shepherd
Thats physical addresses .. I think the poster was talking about virtual addresses (that is, before the virtual address translation).

--Tim

On Jun 16, 2013, at 12:14 AM, Owen Shepherd <[hidden email]> wrote:

> Coda Highland wrote:
>>
>> Unless I'm wrong, ASLR isn't restricted to 48 bits. Virtual memory
>> allocation can use whatever addresses it wants.
>
>
> The hardware itself is physically limited to 48-bits.  Each page is 4kB, plus there are 4 layers of page tables, bringing the total up to 48 bits.
>
> The processors throw an exception on a memory access if bits 63-48 don't match bit 47.
>
> This is all baked into silicon


Reply | Threaded
Open this post in threaded view
|

Re: Integer subtype and NaN trick

Coda Highland
I was, but Owen's right -- the part of the system responsible for
doing the address mapping is implemented in hardware.

/s/ Adam

On Sun, Jun 16, 2013 at 4:02 PM, Tim Hill <[hidden email]> wrote:

> Thats physical addresses .. I think the poster was talking about virtual addresses (that is, before the virtual address translation).
>
> --Tim
>
> On Jun 16, 2013, at 12:14 AM, Owen Shepherd <[hidden email]> wrote:
>
>> Coda Highland wrote:
>>>
>>> Unless I'm wrong, ASLR isn't restricted to 48 bits. Virtual memory
>>> allocation can use whatever addresses it wants.
>>
>>
>> The hardware itself is physically limited to 48-bits.  Each page is 4kB, plus there are 4 layers of page tables, bringing the total up to 48 bits.
>>
>> The processors throw an exception on a memory access if bits 63-48 don't match bit 47.
>>
>> This is all baked into silicon
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Integer subtype and NaN trick

Miles Bader-2
In reply to this post by Tim Hill
Tim Hill <[hidden email]> writes:
> Thats physical addresses .. I think the poster was talking about
> virtual addresses (that is, before the virtual address translation).

My understanding is that this limitation is on virtual addresses
(physical addresses are often even _more_limited).

-miles

--
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Reply | Threaded
Open this post in threaded view
|

Re: Integer subtype and NaN trick

Owen Shepherd
AMD64 is architecturally limited to 56-bit physical addresses and 48-bit sign extended virtual addresses at present.

Individual microarchitectures must all support the 48-bit virtual addressing, but can have smaller physical address spaces. Some Atoms, for example, only have 32-bit physical addressing support.
17 June 2013 02:37

My understanding is that this limitation is on virtual addresses
(physical addresses are often even _more_limited).

-miles

17 June 2013 00:02
Thats physical addresses .. I think the poster was talking about virtual addresses (that is, before the virtual address translation).

--Tim



16 June 2013 08:14
Coda Highland wrote:


The hardware itself is physically limited to 48-bits.  Each page is 4kB, plus there are 4 layers of page tables, bringing the total up to 48 bits.

The processors throw an exception on a memory access if bits 63-48 don't match bit 47.

This is all baked into silicon
16 June 2013 07:53
On Sat, Jun 15, 2013 at 10:35 PM, Miles Bader [hidden email] wrote:
Coda Highland [hidden email] writes:
The problem is that on modern OSes, you can't assume that you can
fit a 64-bit pointer in 48 bits.
My impression was that current implementations of the x86-64
architecture only use 48 bits of addresses, requiring the upper 16
bits to be identical.  Has this changed with very recent
implementations?

Unless I'm wrong, ASLR isn't restricted to 48 bits. Virtual memory
allocation can use whatever addresses it wants.

This is (part of) why LuaJIT demands to use the low 2GB.
Yeah the 2GB limitation is a huge lose... but that's obviously a lot
more restrictive than necessary...

Well, there are ways around it in LuaJIT.

/s/ Adam

16 June 2013 06:35
Coda Highland [hidden email] writes:
The problem is that on modern OSes, you can't assume that you can
fit a 64-bit pointer in 48 bits.

My impression was that current implementations of the x86-64
architecture only use 48 bits of addresses, requiring the upper 16
bits to be identical.  Has this changed with very recent
implementations?

This is (part of) why LuaJIT demands to use the low 2GB.

Yeah the 2GB limitation is a huge lose... but that's obviously a lot
more restrictive than necessary...

-miles