OSDev.org

Ivan Godard, CTO of Mill Computing, Inc., will be giving a talk at Facebook.

The particulars:
Monday, July 14, 2014
Doors open at 10:30 AM, Talk is from 11 AM to 12:30 PM
1 Hacker Way, Bldg 10
Menlo Park, CA 94025

Enter via the left lane of the Willow Road entrance. There is visitor parking along the front of Building 10, but if all of those are taken there is overflow parking across the street. Guests should come to Building 10 and sign in. They will then be escorted to Room 11.2. Our hosts at Facebook are Edwin Smith and Jason Evans.

This will be the ninth topic publicly presented on the Mill general-purpose CPU architecture. It will cover the methods used to perform software pipelining on the Mill Architecture. The talk will assume some general familiarity with software pipelining.

Software pipelining on the Mill CPU:
Instant pipeline: add loop, no stirring needed

The Mill CPU architecture is very wide, able to issue and execute 30+independent MIMD operations per cycle. Non-looping open code often cannot use this raw compute capacity, but fortunately >80% of cycles are in loops. Loops potentially have unbounded instruction-level parallelism and can absorb all the capacity available – if the loop can be pipelined.

This talk addresses how loops are pipelined on the Mill architecture. On a conventional machine, pipelining requires lengthy prelude and postlude instruction sequences to get the pipeline started and wound down, frequently destroying the benefit of pipelining the main body. Conventional pipelining can be of negative benefit on short loops, especially “while” type loops whose length is unknown and data dependent. Not so on a Mill: Mill pipelines have neither prelude nor postlude, and early conditional exit has no added cost.

Pipelines on conventional machines also have problems with loop-carried data, values produced by one iteration but consumed by another. Conventional code must resort to bucket-brigade register copies, or fail to pipeline altogether. Even architectures like the Itanium, which have special hardware to support pipelining, provide it only for the innermost loop. In contrast, the Mill needs no copies and can pipeline outer as well as inner loops.

Familiarity with prior talks in this series, especially the Belt and Metadata talks will be helpful but not essential.

Videos and other material about other aspects of the Mill can be found at http://millcomputing.com/docs.

Previous mentions of the Mill CPU on this forum here and here.

And the talk is now online!

http://millcomputing.com/topic/pipelining/

If only that guy wouldn't make me fall asleep everytime I try listening.

I just read through the slides (don't have time for the video atm) and they're pretty clear, at least with a bit of context about the belt, etc. Probably missed a few details though.

Set the playback speed to x1.25.

When I look this address up in Google Maps I see farm and highway. Is Facebook in the countryside?

So, I went poking around the website, noticed there was absolutely nothing on simulators, and only referential talk regarding to functional compilers. Is there anything of either out there for practical use out there yet?

Nothing's out there yet (probably because they're filing all their patents first), but in the videos they've explained that it's been running in simulation for several years (they show some of it here: http://millcomputing.com/docs/specification/), and they had a mostly functional compiler which they are now porting to use LLVM as the backend (so it sounds like it's in a less functional state now).

That's right, no public sim and no hardware but we are working hard towards both.

The area of most interest to armchair OS devs is perhaps the security model: you can have millions of protection environments and pass control between them - via "portals" - without changing HW thread. Now you can run a conventional kernel on it, but you also have the possibility to build an OS that has some meaningful subdivision of the classic "task"/"process", and even pass messages between mutually distrusting peers without kernel intermediation! This'd be the kind of discussion I'd welcome answering

I'm actually well aware of the issues behind the lack of disclosure, so I was simply hoping there was enough of handholds to start with anything practical, but I suppose I'll have to wait for the specifications to be actually able to draft proper design sketches.

One thing I did realize is that the architecture is by virtue of its design pretty much impossibly written for in oldfashioned assembly. How will you be providing the developer access to any such system call or control register mechanic?