Mill CPU Specification [video] | Hacker News Reader

Mill CPU Specification [video]

millcomputing.com

103 pointsRusky32 comments

(Mill team)

We started with 6 planned talks; it has since grown to 9, and shows no signs of stopping there :)

So if you have a subject you want us to explain, or you want to invite us to give a talk at your uni or workplace (no promises!), please just ask (here or on the Mill forums http://millcomputing.com/forum/the-mill/ or mail me: will at mill computing dot com)

How big is the Mill team, by the way?

So I think all fans of the talks would really love to have a little Mill CPU of their own to play with for some hacking project.

I imagine high prices due to economies of scale will be a problem in the beginning, but if we think longer term and assume you guys overcome that initial hurdle, any dreams of incorporating the Mill into a platform like Raspberry Pi or Arduino?

We fully expect dev boards to be available, although hopefully you'll be able to buy high-end Mill chips too.

It would be really nice to have a Mill simulator, perhaps running on a web page.

Unfortunately, a simulator running in javascript—and that's what you're suggesting, one way or the other—would run so amazingly slowly that it would be completely useless. Especially one which is, if I understood the latest talk correctly, sub-cycle accurate.

(To give you an idea, I think I recall Ivan saying that their simulator takes/would take 1 week to boot linux—and that's in c!)

We have x86 simulator in JS: http://bellard.org/jslinux/ It's slow but usable. With ISA specification someone could make Mill version.

I'm sure that their simulator comprises some debug tools. That's why it's so slow.

Ah, good call. I was thinking of the sort of low-level simulator you'd want to play around with an unfamiliar architecture; but as the technical notes on that link say, no single-stepping. Once you want to actually be able to slow things down enough to watch a system run, then it's typically harder to speed them up again, unless you truly have two separate emulation modes which can switch off. It's doable.

I'm really surprised that Ivan is both a great engineer and a great speaker.

Probably because "If you can't explain it simply, you don't understand it well enough."

I'm waiting for boards with your CPU. I really want to port some software on it.

> Probably because "If you can't explain it simply, you don't understand it well enough."

People consider different things as simple. For example I often consider very abstract mathematics as very easy to understand (since I always thought in a rather abstract way - thus this kind of explanation is very natural for me), while most people consider my kind of explaining things as "unnecessary complicated".

Don't tell me that I haven't understood the topic. When talking about topics that I understood worse, I often tend to give much simpler (and better understandable for "ordinary people") explanations, since I haven't understood the complex connections and thus I'm unable to give a much "simpler" (in my terms; "more complicated" in terms of most people) explanation.

Any chance you could also update the slides as PDFs in addition to all the videos, and maybe even PDF document/HTML versions of the same information in textual form? Some of us prefer reading stuff to watching a talk.

Yup, looks great. Thanks!

One subject which would be interesting would be the changes needed to Linux and to Linux SW to make them work efficiently on the Mill with its unified address space.

I'm thinking about COW fork, mmap where I don't find it obvious on how it would work on the mill..

Also are there features on the Mill which are designed to make GCs work more efficiently?

Excellent feedback! Yes and yes, we will do this type of talk and explain fork() :)

It took me a while (I'm a bit slow on hardware stuff) but I think I understand now why the Mill is A Good Thing.

It can be thought of as a design abstraction layer between hardware platform developers and hardware manufacturers (with a few considerations, as mentioned in the video) which allows rapid hardware development in a way that programming languages (as opposed to assembly) allow rapid software development.

I previously thought it was just a new CPU design (like they come along every day...) but now I think they're heading in the right direction here. Rapid development cycles for hardware with a much more approachable function description language.

Need a chip that does what your old chip does but with newer crypto / media codec / random protocol feature? Load up the previous one, write the new functions in (almost) C++, sim it, test it, send it off to the fab, hardware guys apply unicorn spray and bake in a pressure cooker (or something), product. Hopefully it will work something like that.

He mentions hardware in 2 years (maybe). Is this actually on the horizon? I'm excited by the current state of the sim, but the first hardware (and proof of concept) would be great to see!

It's a substantial reduction in costs, but fab set-up costs for a given design alone are still extremely high ($millions), so it won't be something you do on a whim.

the crypto and media codec stuff are not part of the CPU, they are IP cores on the same SoC as the CPU. So to update to the new media codec and crypto, you can spin a new SoC with the same CPU as the previous one but with added IP cores. The CPU can be ARM or Mill, it won't matter, and the IP cores are exposed to the CPU as IO devices though MMIO. I don't see the big advantage for Mill for this application.

Well, I know what I'm watching tonight.

Pretty much every Mill CPU talk in the series has blown my mind in one way or another (which is to say, taking things that sound wild, weird or impossible at first, and carefully demonstrating how they're all actually simple and straight-forward when you start from the right axioms), and I expect this will be just as good.

Just started to watch this presentation and it strikes me that what they do with C++ as a meta language resembles a lot what Haskell programmers do with Haskell and EDSLs.

The note about overloading the comma operator remembers me the idea that monads (and the do notation) gives us a programmable semicolon.

Here's an example of a fun variant of the idea where something that looks like BASIC is embedded in Haskell: http://augustss.blogspot.be/2009/02/more-basic-not-that-anyb...

The same author also made bindings to LLVM that still is in the same realm.

They're called Embedded Domain-Specific Languages, Ruby is used quite often for the same purposes.

If you're interested in the subject, then I'd recommend Martin Fowler's excellent book: http://martinfowler.com/books/dsl.html

I have mentioned EDSLs in my comment... and yes they can be found everywhere. Lispers are well known for creating DSLs because of their macro system.

If you really can hit 10x performance/watt then this could be massive in the world of wearables.

Imagine a smart watch going from 3-5 days standby to 30-50 days standby. Heck, at that level you might even be able to charge kinetically..

I don't think the Mill is designed for this use case, exactly. Optimizing peak performance per watt is very different from optimizing for low power. The latter would be dominated by shutting off circuits, different sleep states, lowering leakage and voltage, etc.

Something like a GreenArrays chip might be a better fit for that direction (though very unconventional).

A good way to learn about low power is to play around with an MSP430 chip. TI was selling trial kits for something like $5 or so. (Cheaper than the included USB.)

Oblivious software person here: what does this new architecture mean for folks writing software on top of it? Is this a way to gain extra performance in single-threaded applications? What happens to concurrency? What's the long-term vision?

fairly oblivious also, but here are some semi-informed guesses:

> what does this new architecture mean for folks writing software on top of it?

i think the plan is to use a custom compiler (made out of LLVM components) to build usual C to run within usual linux, except linux is on top of L4.

> What's the long-term vision?

rather than maximizing "compute per chip", maximize "compute per electricity." (and, presumably, cloud all the things.)

IIRC L4 is just a proof-of-concept thing to port, not necessarily what they plan for everyone to use. The Mill's security model is well-suited for a microkernel (it doesn't have the overhead traditional architectures have with microkernels).

The security model is probably the biggest thing people writing software will notice- instead of a user/kernel split with expensive transitions between separate address spaces, it's a single address space with cheap (on the order of a shared library call) transitions between arbitrary protection domains (turfs).

I want to buy one so badly.

cpuid: ACTUALLYMILL

The list of Vendor IDs is quite amusing:

http://en.wikipedia.org/wiki/CPUID#EAX.3D0:_Get_vendor_ID

Yeah, "AMDisbetter" was quite amusing. Until K7 which was really better.

Reply on news.ycombinator.com