Mill CPU Architecture

[richardman]

If you have concrete technical questions about the Mills, and are interested enough to write about them in a forum, I'd encourage you to contact the people involved, as it's unlikely anyone else would be able to answer them.

You may want to talk about the "right ways" to do marketing, or how to introduce a new CPU architecture properly etc. At least the answers you get here would be interesting answers. Technical questions though, would unlikely to get interesting or at least technically correct answers here.

[tggzzz]

That makes any such opinion not worth the paper it isn't written on.

I personally don't care if Mill succeeds or fails, I have zero vested interest in it.

That is clear, since apparently you have zero interest in bothering to find out about it!

But public perception of a product is very important. If significant amount of people will get something into their head, it is very hard to convince them otherwise.

I doubt you could be convinced, since there is little evidence to believe you are prepared to find out and understand what's already been publicised.

"Richardman"'s post #50 is sane, and the public perception of your stance would be improved if you followed his suggestions.

[hamster_nz]

Wow... Nice weekend wolf pack being stirred up by somebody  sharing their (valid) opinions, in an open public space.

Calls of "the information is out there", with no links count for nothing. The only recent information I can find is thing like "rasing funding to make a proof of concept FPGA prototype (just like in 2013). Tumbleweeds are blowing through the forum....

Apparently the engineers are working for 'sweat' equity'', and 13 years has not been long enough to write enough HDL to prove the concept.

Money can't be an issue - as the engineers working for promises, and $1300 will get you 200,000 LUT6s and 400,000 flip-flops, plus plenty of RAM blocks - more than enough for a demo CPU. plus a toolset license.

From afar it looks pretty much like a cult!

[tggzzz]

Calls of "the information is out there", with no links count for nothing.

Likewise "I don't understand it and I can't be bothered to do basic research, but I'll make a statement anyway" count for nothing.

I previously provided one link to informed statements, in reply #1. Here's another, which isn't exactly difficult to uncover: http://millcomputing.com/

Money can't be an issue - as the engineers working for promises, and $1300 will get you 200,000 LUT6s and 400,000 flip-flops, plus plenty of RAM blocks - more than enough for a demo CPU. plus a toolset license.

A hardware implementation isn't the major problem, so buying a few FPGAs is a distraction from the difficult and novel issues: the toolchain and architecture.

Some people are happy to work for free; I would be on a sufficiently interesting problem where I could make a decent contribution. In the past I've been known to turn down higher paying jobs in favour of noticeably lower paying jobs because I preferred the work at the latter.

From afar it looks pretty much like a cult!

So does most technology in its infancy.

[Sal Ammoniac]

Here is a video on the Mill Security. Again I am no expert, but it did sound clever to me 

Is that Gandalf the White narrating it?

[TheOtherDave]

Even obvious questions seem unanswered...

"So if the CPU us a family, each with different capabilities. How can a compiler statically schedule instructions/operations when the exposed micro-architecture changes underneath it between different family members?"

I'm guessing the answer would be a magic wand wave like "Oh, we plan to add another layer abstraction, which dynamically recompiles the executable to take advantage of the CPU it is running on - it's a easy to solve software problem" - pleasing to the software people in the audience (as hardware is a software problem from their perspective), but doesn't answer the question.

https://youtu.be/D7GDTZ45TRw

TL;DR: Software gets distributed in something like an IR or bytecode, which is then compiled for the specific CPU at install time.

[brucehoult]

I remember Itanium - another promising CPU  'family', that offered lots of promise, from some of the world's greatest minds.It was deeply pipelined, supported by big names (Intel, HP...), it took years to get to market, and when it did it had a few rough corners when it came to interrupta, traps and dealing with memory latency.

If I remember correctly, the vendors also claimed that it was superiour - the smarts were inthe software tool chain, and just neede better compilers to unleash the beast within.

No matter how much money was thrown at the project (and a lot of money was thrown at it)  it just couldn't outperform a CPU that can schedule instructions dynamically at runtime as data became available.

Given the slow time to a viable product, The Mill must have some big technical issues slowing it down....

Mostly I believe it's slow because it's a small team, largely working for sweat-equity. Ivan offered me to join about three years ago but I definitely needed something with a salary at the time. They have got some funding now, and can pay salaries, so that's an advance.

They have quite a lot of software tools. Generators for models of different sizes, simulators, compiler. I'd have hoped that by now it would at least be possible to load small or medium Mill models into an FPGA. I don't *think* they've got to that stage yet.

On the other hand, that is something that takes 3 or 4 years for a new design even at huge companies like Intel or Samsung with huge teams working.

[legacy]

so, it's opensource project, which will take 4-5 years from now
can I get a full job there? at MIT? good salary? 

[tggzzz]

so, it's opensource project, which will take 4-5 years from now
can I get a full job there? at MIT? good salary? 

What makes you think that?

For what is actually is, see http://millcomputing.com/

[legacy]

wow, the ISA goes very long 

[legacy]

What makes you think that?

This interview

[legacy]

Oh, listed to what he says in the interview: the assembly compiler comes automagically from a specification file, as well as the C compiler (back end) and the first part of the simulator, top to bottom

Interesting to extend the design.

[brucehoult]

wow, the ISA goes very long 

Not really.

When you look at something like ...

Code: [Select]

f2uefse - Exactly convert a binary floating point value to a unsigned integer, rounding toward even and producing saturating result values.

.. and another 100 instructions like it, it's really just one instruction "convert" with half a dozen subfields that can be mixed arbitrarily. IBM has always done that with e.g. System/360 and Power, while various other companies have a single "cvt" instruction mnemonic with a bunch of optional attributes, perhaps after the operands. It makes no difference to the actual complexity of the machine, just the documentation.

ARM has gone that way too with Aarch64, with zillions of mnemonics such as CSEL, CSET, CSETM, CSINC, CSINV, CSNEG that are all actually all the same conditional select opcode with options to invert or increment the 2nd argument. And mnemonics as far removed as SXTB/SXTH/SXTW (sign extend) and ASR/LSR/LSL immediate are actually just special cases of a single BitFieldMove opcode -- in fact it turns out you can sign extend from ANY bit position with a single instruction. not only 8/16/32.

I think the idea is probably that it simplifies the assembler/disassembler, by making the parsing (text or binary) simpler at the expense of having many more patterns to match. Well, and makes life a bit simpler for the programmer too, not having to remember that a BitFieldMove with imms != '111111' && imms + 1 == immr is the way to get a left shift.

[brucehoult]

And I have yet to see it demonstrated, not even running slowly in a high end FPGA.

Very much unlike RISC-V where many cores fit can fit on a low-end FPGA, and I even have one in hard silicon on my bench.

A very interesting comparison, and really at the heart of any concerns I have about The Mill.

RISC-V has been developed by a similar-sized team, starting later. They iterated the ISA over the first four years, but did it while at the same time creating not only compiler and binutils and multiple sims but also FPGA implementations *and* fabbing multiple generations of working chips. They also have a high level processor family generator tool with completely plug-and-play selection of options such as caches, MMUs, several FPU options, several multiplier and divider and shifter options (including "none" for all of those), 32 bit or 64 bit. You can also choose between 3 stage or 5 stage inorder pipeline, or (not 100% integrated yet) multiple dispatch out-of-order. Today there is one RISC-V chip you anyone can buy (I got my HiFive1 board in January), plus several other companies have their own chips for internal use. There must be near to a dozen implementations you can put into an FPGA.

I guess there are two major obvious differences:

1) the RISC-V people did the work while on cosy academic salaries, with financial/practical support from big companies such as Intel, Samsung, TSMC. Mill has been largely self-funding, without any tasty grants.

2) RISC-V is being done in an open-source manner, with the intention of changing the world for the better and with increasing amounts of work being done by the community, rather than getting rich (though there are likely to be pretty nice consulting and customisation opportunities around it). The Mill people want to change the world too, but they want to get filthy rich doing it.

I'd like to see both succeed.

[legacy]

the intention of changing the world for the better and with increasing amounts of work being done by the community, rather than getting rich

oh, well ... so opensource now actually sounds like the political theory derived from Karl Marx, advocating class war and leading to a society in which all property is publicly owned and each person works and is paid according to their abilities and needs.

[legacy]

(but I don't trust it)

[brucehoult]

the intention of changing the world for the better and with increasing amounts of work being done by the community, rather than getting rich

oh, well ... so opensource now actually sounds like the political theory derived from Karl Marx, advocating class war and leading to a society in which all property is publicly owned and each person works and is paid according to their abilities and needs.

It's difficult to see how that could be the case.

Open source is based on purely voluntary interactions, done because each party calculates that they gain more benefit from doing so than the costs. You may participate or not, as you wish, or participate in a rival open source or for-profit project.

Marx's theories on the other hand can only be put into practice by means of compulsion. Even if the compulsion starts with the best of intentions it's absolute power leads inevitably after a period to the most ruthless and barbaric rising to the top of the heap. Dissent will swiftly lead to a bullet in the back of the head, or a one way trip to a forced labour camp.

I'm writing these words about 2 km from Butyrka prison, and five km from Lubyanka. Look them up. Solzhenitsyn has a lot of information about both.

[legacy]

well, I have given a look to the architecture, and listened a few presentations

What I think: I don't like a lot of things in this architecture

First of all: the belt! It's a queue register which shifts on the right (consequentely it loses a slot) every clock edge. This belt has been designed to solve the "renaming registers" problem which ussually afflicts VLIW-like architectures. So, you have a lot of processing in parallel, no general purpose registers, and the belt is the only way to pass and get information to and from them.

So, when you have to issue an operation, say C = A OPP B, you have to rename A, B, C in term of belt positions.

This point varies at every clock edge, and you also need to have an optimal scheduling data flow to understand the correct order.

Therefore is definitively something you can't assemble by hand like we have always done with 6800 or 68000, you need a compiler, it's a must!

It's even worse than the pipelined version of MIPS without the automatic stall and hazard unit, I mean where you have to manually consider every dependency between stages and registers and manually reschedule in the correct order, or fill a NOP between operations as well as you have to do with in order to solve the "delayed slot" which always happen on a branch.

Well, there are RISC-architectures (like 88K)  where the hardware can automatically fill a NOP after the branch, you just need to set the proper bit, and forget about it.

RISC like MIPS are hard to be programmed in assembly. PowerPC is more friendly but even more complex, ARM is the most friendly in the family.

Btw all of those are still programmable in assembly, whereas Mills is definitively a no-go since it's virtually impossible for a human being.

The belt-solution looks horrible for me 

[legacy]

It was already said on the publish talk on hackaday (2013). D'oh 

[obiwanjacobi]

They (Mill Computing) added a few new videos recently for those that are interested:

The Mill CPU Architecture – Inter-Process Communication (12 of 13)


The Mill CPU Architecture – Threading (13 of 13 & more to come)


It seems they're moving towards an FPGA demo version too.

[rstofer]

This project has been going on for a long time.  I would have expected hardware, even an FPGA, a long time back.
It will be interesting to see the concept played out with real code on real hardware.

[helius]

Performance on FPGA is going to be far short of what they are promising and there isn't much benefit to making that public. They're planning on doing all the compiler and OS development themselves so there is also relatively little reason for early access tools to be released externally.

[hamster_nz]

Performance on FPGA is going to be far short of what they are promising and there isn't much benefit to making that public. They're planning on doing all the compiler and OS development themselves so there is also relatively little reason for early access tools to be released externally.

Rule of thumb, CPUs on an FPGAs run at 10% the clock speed of highend CPUs. A "low end" 150 MHz FPGA implementation would be plenty enough to show that the design has potential. It was supposed to be a fight against the complexity of current CPUs, so what makes it so complex that it can't be demonstrated?

It was/is also claimed that the Mill avoids the hard stuff like register-renaming and out-of-order execution, so it should be just a few thousands of lines of RTL - after all, it is claimed all the hard work is in the software layer.

They are touting as covering the full range of computing needs from embedded to HPC.  An RTL/FPGA implementation of the smallest design would at least build some faith that it isn't vaporware after nearly 15 years of development. Yes, FIFTEEN YEARS. Wikipedia: It has been under development since about 2003 by Ivan Godard and his startup Mill Computing, Inc.

If Mill Computing can't show a booting CPU after 15 years because it is worried that the "simple" design will be too slow is worrying about the wrong thing.

The RISC-V project, where FPGA implementations were available from early on, were very useful for popularizing the architecture, and making it easy for tools to be developed and tested, and enabled the transition to custom silicon much easier.

To me, it seems to be a vacuum for VC money, and vacuuming up the spare time for "keen but green" engineers trying to make a break for themselves.

[ataradov]

10% is generous, IMO.Their whole architecture is based around having a lot of multiplexing logic. This bothered me the whole time he was explaining stuff. I doubt it will have good performance in FPGAs, and possibly even when hardened.

The whole belt management is a nightmare from hardware point of view, unless I'm missing something from his explanations.

On the other hand, even if it runs at 10 MHz, it still would be nice to see something working.

But for now they are filing patents and collecting checks from VCs.

[hamster_nz]

10% is generous, IMO.Their whole architecture is based around having a lot of multiplexing logic. This bothered me the whole time he was explaining stuff. I doubt it will have good performance in FPGAs, and possibly even when hardened.

How strange... I though the opposite. Wasn't it was all about having "the belt" were data flowed through a long circular pipeline, where only a few functional units were connected to the belt at any given step, and each functional unit consumed or produced new values to go onto "the belt". This limited fan-in/fan-out an multiplexing, and allowed the design to be efficiently spread out over the silicon (avoiding that "Rent's rule" stuff).

Maybe that was a few 'design pivots' ago. Maybe that is now an layer of abstraction or software model, on the way down to the real hardware, which is a bunch of trained turtles with small glass beads.