6 ms·

What interested me in the design of the Mill CPU is how it throws out the usual design of machine language. I'm not talking about assembly language, and I know

by ansible 11y ago

What interested me in the design of the Mill CPU is how it throws out the usual design of machine language. I'm not talking about assembly language, and I know the difference, BTW. In the name of software compatibility, we're still trying to program CPUs using machine language that wouldn't be so strange to a programmer from the 1980's. Sure, there's more registers, and some fun new stuff, but it isn't all that different. Except that in the 1980's, the CPU actually implemented those instructions. These days, it is all a lie, especially with regards to things like register sets and aliasing. Yes, of course, logically, what the programmer wanted to happen does, but today even programming at assembly level, you are far, far removed from what the CPU is actually doing. Edit: Here's the website: http://millcomputing.com/docs/ http://millcomputing.com/docs/

dang 11y ago
> how it throws out the usual design of machine language Now I'm curious. How does it?
- w0000t 11y ago
  No ordinary registers. Instead you have a FIFO queue( belt ), where every element( register ) is accessible and has a relative address( offset ). https://www.youtube.com/watch?v=QGw-cy0ylCc&list=PLFls3Q5bBInj_FfNLrV7gGdVtikeGoUc9&index=2 https://www.youtube.com/watch?v=QGw-cy0ylCc&list=PLFls3Q5bBI...
gizmo686 11y ago
It is worth noting that many of the Mill features are also a "lie" (for example, the belt is still just registers and register renaming). Its just that the Mill uses lies designed for modern processor technology.
- w0000t 11y ago
  False. Mill does not do register renaming. ( Or use "lies". I failed to comprehend you second sentence. ) Here is a talk from one of the designers explaining how it is done: https://www.youtube.com/watch?v=QGw-cy0ylCc&feature=youtu.be&t=24m38s https://www.youtube.com/watch?v=QGw-cy0ylCc&feature=youtu.be...
  - stdbrouw 11y ago
    "Lie" in this context means something like "abstraction or metaphor that doesn't present itself as such."
- zurn 11y ago
  Yes, registers and the belt are just ISA features. Register renaming is a behind the scenes implementation tech to mitigate the problems of register semantics. It has unwanted costs that a belt machine doesn't have to pay, and it's incorrect to say that Mill does register renaming in the traditional sense of the word. Indeed that's what the #1 paragraph at https://millcomputing.com/docs/belt/ https://millcomputing.com/docs/belt/ says: "A large fraction of the power budget of modern superscalar CPUs is devoted to renaming registers: the CPU must track the dataflow of the executing program, assign physical registers and map them to the logical registers of the program, schedule operations when arguments are available, restore visible state in the event of an exception—all while avoiding register update hazards."
- Symmetry 11y ago
  The belt isn't an abstraction of the structures in a modern OoO CPU corresponding to registers and renaming but rather the bypass network further down the pipeline. The belt like the bypass network only has to store data for limited periods and the translation is much simpler than what an OoO CPU has to do when renaming registers.
gsg 11y ago
> In the name of software compatibility You say this as if it is a bad thing (or am I misinterpreting here?), but compatibility is enormously valuable. That's why the strategy of choosing compatibility over cleanliness of architecture is so widespread in successful complex systems - ISAs, OSs, the Web, programming languages, etc etc. It's hard to love the resulting complexities, but remaining compatible really is almost always the right thing to do.
- sklogic 11y ago
  > but remaining compatible really is almost always the right thing to do. Luckily, not that much any more. In GPUs, for example, nobody cares, since nobody is carrying binaries around.
- ansible 11y ago
  Software compatibility is both good and bad. If we were in the habit of recompiling from source with each CPU generation (this presumes source is available), that would allow much more innovation in machine language. And then the design of that machine language would more closely resemble the actual design of the CPU. But there are such significant advantage to remaining binary compatible, that I'm not surprised with how things actually turned out.
  - gsg 11y ago
    This is an interesting design question - which layer should be backwards compatible and under which significant freedom of design is allowed. I'm not at all sure that the best answer is "source code". For x86 CPUs the compatible layer has been the ISA and that has turned out pretty damn well, suggesting that source compatibility is not the only and may not be the most effective choice. Particularly if the source is C, which is rather ambiguous compared to most machine languages.
    - ansible 11y ago
      I'm not at all sure that the best answer is "source code". For x86 CPUs the compatible layer has been the ISA and that has turned out pretty damn well, suggesting that source compatibility is not the only and may not be the most effective choice. I disagree, though I see your point. If the x86 instruction set had been designed to be implemented in various ways depending on the available semiconductor technology, then that would be a much better situation. However, the basics of x86 were designed in the 1980s to be directly implemented in the hardware of the time. If you were designing an ISA expressly to insulate software from the hardware, I'm sure there are dozens of design choices that would be made differently. Ditto for amd-64.
deleted 11y ago
[deleted]

by ansible 11y ago

dang 11y ago

> how it throws out the usual design of machine language Now I'm curious. How does it?

w0000t 11y ago
No ordinary registers. Instead you have a FIFO queue( belt ), where every element( register ) is accessible and has a relative address( offset ). https://www.youtube.com/watch?v=QGw-cy0ylCc&list=PLFls3Q5bBInj_FfNLrV7gGdVtikeGoUc9&index=2 https://www.youtube.com/watch?v=QGw-cy0ylCc&list=PLFls3Q5bBI...

gizmo686 11y ago

It is worth noting that many of the Mill features are also a "lie" (for example, the belt is still just registers and register renaming). Its just that the Mill uses lies designed for modern processor technology.

w0000t 11y ago
False. Mill does not do register renaming. ( Or use "lies". I failed to comprehend you second sentence. ) Here is a talk from one of the designers explaining how it is done: https://www.youtube.com/watch?v=QGw-cy0ylCc&feature=youtu.be&t=24m38s https://www.youtube.com/watch?v=QGw-cy0ylCc&feature=youtu.be...
- stdbrouw 11y ago
  "Lie" in this context means something like "abstraction or metaphor that doesn't present itself as such."
zurn 11y ago
Yes, registers and the belt are just ISA features. Register renaming is a behind the scenes implementation tech to mitigate the problems of register semantics. It has unwanted costs that a belt machine doesn't have to pay, and it's incorrect to say that Mill does register renaming in the traditional sense of the word. Indeed that's what the #1 paragraph at https://millcomputing.com/docs/belt/ https://millcomputing.com/docs/belt/ says: "A large fraction of the power budget of modern superscalar CPUs is devoted to renaming registers: the CPU must track the dataflow of the executing program, assign physical registers and map them to the logical registers of the program, schedule operations when arguments are available, restore visible state in the event of an exception—all while avoiding register update hazards."
Symmetry 11y ago
The belt isn't an abstraction of the structures in a modern OoO CPU corresponding to registers and renaming but rather the bypass network further down the pipeline. The belt like the bypass network only has to store data for limited periods and the translation is much simpler than what an OoO CPU has to do when renaming registers.

gsg 11y ago

> In the name of software compatibility You say this as if it is a bad thing (or am I misinterpreting here?), but compatibility is enormously valuable. That's why the strategy of choosing compatibility over cleanliness of architecture is so widespread in successful complex systems - ISAs, OSs, the Web, programming languages, etc etc. It's hard to love the resulting complexities, but remaining compatible really is almost always the right thing to do.

sklogic 11y ago
> but remaining compatible really is almost always the right thing to do. Luckily, not that much any more. In GPUs, for example, nobody cares, since nobody is carrying binaries around.
ansible 11y ago
Software compatibility is both good and bad. If we were in the habit of recompiling from source with each CPU generation (this presumes source is available), that would allow much more innovation in machine language. And then the design of that machine language would more closely resemble the actual design of the CPU. But there are such significant advantage to remaining binary compatible, that I'm not surprised with how things actually turned out.
- gsg 11y ago
  This is an interesting design question - which layer should be backwards compatible and under which significant freedom of design is allowed. I'm not at all sure that the best answer is "source code". For x86 CPUs the compatible layer has been the ISA and that has turned out pretty damn well, suggesting that source compatibility is not the only and may not be the most effective choice. Particularly if the source is C, which is rather ambiguous compared to most machine languages.
  - ansible 11y ago
    I'm not at all sure that the best answer is "source code". For x86 CPUs the compatible layer has been the ISA and that has turned out pretty damn well, suggesting that source compatibility is not the only and may not be the most effective choice. I disagree, though I see your point. If the x86 instruction set had been designed to be implemented in various ways depending on the available semiconductor technology, then that would be a much better situation. However, the basics of x86 were designed in the 1980s to be directly implemented in the hardware of the time. If you were designing an ISA expressly to insulate software from the hardware, I'm sure there are dozens of design choices that would be made differently. Ditto for amd-64.

deleted 11y ago

[deleted]