Lua 5.3 work1 Considering math.isinteger or type()

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

Re: Lua 5.3 work1 Considering math.isinteger or type()

Sean Conner
It was thus said that the Great Jay Carlson once stated:

> On Jul 25, 2013, at 3:43 AM, Sean Conner wrote:
>
> >  As a side project, I'm playing around with bindings to ptrace().  ptrace()
> > is a function that deals primarily with addresses [1].  On a 32-bit system
> > there is no real issues [2] but on a 64-bit system it really is an issue
> > [3].
>
> Bet it isn't. Which architecture is handing you userspace pointers outside
> the range of precise 64-bit doubles? (Amusingly you even get additional
> range if the pointers are 4-byte aligned.)

  If you are asking what architecture am I receiving addresses that exceed
53 bits in size, I haven't fully checked, but I am doing work on some very
beefy 64-bit SPARC boxes at work---I concider it well in the realm of
possibility.

  -spc (Yeah, how many programs assumed the top 8 bits of a 32-bit address
        could be arbitrarily set during the 80s, early 90s?)

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Jay Carlson
On Jul 25, 2013, at 6:04 PM, Sean Conner wrote:

> It was thus said that the Great Jay Carlson once stated:
>> Which architecture is handing you userspace pointers outside
>> the range of precise 64-bit doubles? (Amusingly you even get additional
>> range if the pointers are 4-byte aligned.)
>
>  If you are asking what architecture am I receiving addresses that exceed
> 53 bits in size, I haven't fully checked, but I am doing work on some very
> beefy 64-bit SPARC boxes at work---I concider it well in the realm of
> possibility.

I just spent a couple hours looking for the SPARC T3-T5 implementation supplements to the V9/Oracle 2011 architecture and came up with nothing. Somebody's blog entry implies they did implement the entire 64-bit virtual address space; I'm a little skeptical, but the M5 supports 32 DIMM slots per processor socket, with 16G or 32G DIMMs, so that's an (allegedly) purchasable machine with 1T RAM per socket, with 32 sockets.

This is a NUMA architecture, so if you *did* want to use the million dollar machine to run a single (hopefully massively threaded) process, you'd need 45 bits of address space.

The T2 has a 48-bit limit on virtual addresses. So that's 3*1.5 years of Moore's Law left for that old architecture. Precise, byte-aligned addresses represented in floats would seem to have 8*1.5 years left before real memory outpaced them (at least on Larry Ellison's home computer). Besides ASLR, there are a bunch of hacks which eat virtual address space faster than that ( http://ssdalloc.cs.princeton.edu ) but I dunno what CPUs are gonna do.

>  -spc (Yeah, how many programs assumed the top 8 bits of a 32-bit address
> could be arbitrarily set during the 80s, early 90s?)

The Mac had this problem in spades, and there's a mea culpa on folklore.org about it. I don't remember the Amiga having this problem (aside from maybe Microsoft's awful AmigaBasic), but I bailed from the platform well before I could populate a machine with more than 16M.

I would guess most CPU architects remember 32-bit cleanliness on the Mac with a great deal of pain, since most architectures seem to mandate sign extension, keeping you from doing anything particularly naughty with that high byte.

Jay

[1]: 48M of L3 cache per socket, which is six Agenda VR3s worth of memory, or roughly the size of my first hard drive.
1234