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)
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?
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?
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.
> 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.
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!)
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.
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.
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.
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?
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).
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)