A look at The Machine [LWN.net]

A look at The Machine

Posted Aug 27, 2015 17:30 UTC (Thu) by smoogen (subscriber, #97)
In reply to: A look at The Machine by keithp
Parent article: A look at The Machine

I wonder how long until this pushes the need for 128 bit CPUs and (say 96 bit MMU ) or just moving the 48 number higher in 64 bit cpus since it seems to be more of a "at this point in time we don't see how having it higher would be helpful in our designing this..." type decision.

to post comments

A look at The Machine

Posted Aug 27, 2015 17:48 UTC (Thu) by gioele (subscriber, #61675) [Link] (8 responses)

> I wonder how long until this pushes the need for 128 bit CPUs and (say 96 bit MMU ) or just moving the 48 number higher in 64 bit cpus since it seems to be more of a "at this point in time we don't see how having it higher would be helpful in our designing this..." type decision.

In addition I wonder in how many places one can already find the trick "I will use these extra 16 bits for my own business" based on the justification that "all architectures discard the top 16 bits anyway".

A look at The Machine

Posted Aug 27, 2015 18:01 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Quite a few... One project I know of uses upper 8 bits of pointers for object type tag to help the GC.

A look at The Machine

Posted Aug 27, 2015 18:13 UTC (Thu) by keithp (subscriber, #5140) [Link]

Fortunately, x86-64 requires that the top 16 bits of the virtual address be all the same (either all 1 or all 0), and http://support.amd.com/TechDocs/24592.pdf says that a GPF or Stack fault is generated when this isn't true. So, at least we're somewhat protected from applications doing "bad" things by hiding data up in those bits, unless they're masking them out before use. We've been here before several times, and it looks like AMD took those lessons to heart.

A look at The Machine

Posted Aug 30, 2015 1:21 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (4 responses)

Ooh, Mill is going to shake things up quite a bit here. Four reserved bits: one for use in implementing fork (apparently used to flag relative versus absolute…which hints that maybe the hardware representation is all relative addressing) and three for use by garbage collectors. Sixty remaining address the (flat) memory space. Casting between pointer and int is an instruction (which can presumably return NAR) to make sure you don't muck with the bits.

A look at The Machine

Posted Aug 30, 2015 22:54 UTC (Sun) by keithp (subscriber, #5140) [Link] (1 responses)

At least limited virtual address space is cheaper to hack around than limited physical address space. Swapping virtual to physical mappings is something the cache system understands, while swapping physical to device mappings makes the cache system very unhappy.

Just give us enough bits to address every particle in the universe and we'll be happy, right?

A look at The Machine

Posted Aug 30, 2015 23:15 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Well, with pointers being distinct entities from an integer representation, I imagine one could spec a Mill processor with 128 bit pointers so you'd have 124 (or 120 to expand the GC bits some) bits of address.

Looking back at the slides[1], it appears that there is virtual memory addressing, but there is only one address space. This allows them to put the TLB behind the cache (slide 52). Not sure if that would change things for The Machine.

[1]http://millcomputing.com/docs/memory/

A look at The Machine

Posted Sep 4, 2015 18:39 UTC (Fri) by adler187 (guest, #80400) [Link] (1 responses)

The IBM i (ne AS400/Systemi/etc) MI architecture has been using 128-bit pointers since the 80s and does similar things to distinguish pointers. There are many different pointer types. One is a Space Pointer, which points to a MI space object (a memory region up to 16MiB - 1 page) that can be used for storing data. The bottom 64-bits are the actual 64-bit machine pointer and the top 64-bits are are 0 except for the top bit used to indicate it's a space pointer. If the machine ever goes to a CPU with a larger address space (as has already happened in the 90s moving from 48-bit custom CISC to 64-bit POWER), more bits can be used for the address (I don't know exactly how many bits are reserved for type distinction, though).

The MI architecture has special instructions for manipulating pointers, which prevent casting back and forth between int and if you try it, the tag bit will become unset by the hardware and attempting to dereference the pointer will cause a segmentation fault. This is similar to the CHERI CPU: https://lwn.net/Articles/604298/, though CHERI differs in that it has pointers and "capabilities" and you have to opt-in to capabilities, so applications that assume pointer == long continue to work, but you can get better protection by using capabilities - on IBM i there is no such luck, you have to update your application.

A look at The Machine

Posted Sep 11, 2015 12:12 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

It's nice to know that such problems have been dealt with before. However the set of software which has been exposed is, I suspect, very different for the MI versus the Mill's targets.

A look at The Machine

Posted Sep 3, 2015 7:04 UTC (Thu) by oldtomas (guest, #72579) [Link]

> In addition I wonder in how many places one can already find the trick "I will use these extra 16 bits for my own business"

Since a while, tagging implementations tend to (mis-) use some lower bits out of the realisation that a pointer "to something useful" is divisible by four (gives you tow bits) or even by eight (gives you three).

Guile Scheme is an example, but surely not the only one.

Perhaps time has come to address memory in bigger chunks than 8 bit bytes?

A look at The Machine

Posted Aug 28, 2015 11:15 UTC (Fri) by justincormack (subscriber, #70439) [Link]

Risc-V has a 128 bit instruction set version, for just this eventuality. I think we will see full 64 bit physical addresses arrive fairly soon though to stave off this type of segmentation.