The Mill CPU architecture

[ewmayer]

Friend sent me this link (#7 of a series of 9 talks) on a new security-and-performance-oriented CPU architecture called The Mill:



Some interesting comments in the first 20 mins on the role (and power-hungriness) of the TLB in current arches such as x86: "The power consumption of the TLB in a processor like Haswell is truly phenomenal."

[retina]

It will be interesting to see if they can get enough software backing to make it a major player.

I notice that it has no flags or equivalent state information. So how does one do carry propagation in multiprecision code? I hope that even low level coders are not forced to use the ugly C style constructs of comparing the result to the input value to simulate a carry flag. Ew.

And just like a GPU and Java you don't actually generate binaries from the compilation process, it is all a layer above with some intermediate code and the CPU-specific-software-loader will then create the compatible binary code at runtime. Seems to be just another place to have bugs present.

[jasonp]

There are some very neat ideas incorporated into this design. One of the earlier talks said they had been at it for 10 years.

[retina]

Originally Posted by retina

I notice that it has no flags or equivalent state information. So how does one do carry propagation in multiprecision code? I hope that even low level coders are not forced to use the ugly C style constructs of comparing the result to the input value to simulate a carry flag. Ew.

The forum has a comment about this:

Originally Posted by http://millcomputing.com/topic/metadata/#post-419

There are no condition codes as such; it’s kind of hard to do when you can have half-a-dozen CC-setting operations in each instruction, although some architectures try, using multiple CC registers.

To have the effect of a carry bit, if you know that no argument was a Nar and you do an addux and get a NaR out, then you must have gotten an overflow, but that’s pretty kludgy. Or you could do an adduw and test the first bit in the extended data, but that’s pretty kludgy too.

However, there is an alternative: the current operation set includes addc and subc, with two results: a wrapped value and a carry/borrow. It is not clear whether these ops will stay around though; the only use is in an arbitrary-precision library, and for quad arithmetic on members that don’t support native quad; neither of these seem that common, and it’s not clear that the ops (which would have two-cycle latency) are worth it.

We expect a general triage of the operations set later in the process of an FPGA implementation.

And further down:

It would certainly be possible to have a carry metabit in each byte, and we considered it. After all, there is already a NaR bit in each byte. However, we could not find enough usage for such a design to justify the cost. Perhaps we overlooked some important use for carry ...

My first thought was TLS, and crypto primitives in general, make extensive use of arbitrary-precision code. Maybe I've overlooked something also?

[sanaris]

Now, when casual users quit 100 watt processor range for tablets and iphones, industry could do some really nice computing devices in terms of floating point ops per clock.

Problem is, why only Intel has the balls to do it?

[xilman]

Originally Posted by sanaris

Problem is, why only Intel has the balls to do it?

s/balls/money/