5 ms·

I got excited about Mill a couple months ago after watching some videos (I finally understood a little bit, after seeing their materials pop up for years). It'

by chubot 9y ago

I got excited about Mill a couple months ago after watching some videos (I finally understood a little bit, after seeing their materials pop up for years). It's refreshing to see a design that crosses hardware/software boundaries rather than just hacking on one side of the fence. But then I noticed that Mill is not an ISA but a family of ISAs? (Small, Medium, Large or something like that) They are hacking LLVM so that it knows about all of the ISAs. But doesn't this cause a problem for say JIT compilers? (JVM, every major JavaScript engine) Every single JIT compiler has to know about 4 ISAs? I get that they are similar, but that seems onerous. Debugging tools have to know about them too. Even strace is coupled to the ISA. I think the costs may have been underestimated. Anything that changes the hardware/software boundary is already risky because you have to change two things at once. But if you're going to do that, I would think it should be a single stable interface? In other words I think the coupling between their own compiler tech and the hardware is too close. Not everything is a portable C program. There's still people running Fortran, not to mention non-LLVM based compilers like Go.

Symmetry 9y ago
I think what is supposed to happen is that the JITS generated general assembly for the whole Mill family which then goes through the standard specializer program to work with the particular model. But you're right that changing the hardware/software boundary is really complicated and I expect that to succeed the Mill will have to spend a lot of time incubating in some sort of high end embedded role before the ecosystem needed for a general purpose application processor is there. So things like network switches, cell towers, robots, etc. The sort of thing where you might already be running Linux on top of some sort of RTOS.
infogulch 9y ago
> Every single JIT compiler has to know about 4 ISAs? Actually it's way worse, but much better. Better first: Typically, binary programs targeting the mill don't target a specific machine, but they target a hypothetical "general mill" machine code called GenAsm [0]. GenAsm makes some generous assumptions about the hardware, like infinite belt and presence of machine instructions. Included with each machine is the Specializer [1], a program that takes GenAsm and converts it down to the specialized binary encoding for this specific machine; think of it like a linker. This includes translating infinite belt semantics into finite belts, polyfilling any missing machine instructions with microcode, etc, etc. This process is very fast and the OS can cache the result. JITs can use an API to convert generated GenAsm into runnable machine code which includes running it through the Specializer. The specializer is built along with all the other tooling based on the specification that Ivan mentioned briefly. Now for worse: because mill machines are specification-driven, there could be many more than just 4 ISAs. There could be more ISAs than they have customers depending all on the needs in each case. But it's no big deal because everything targets GenAsm and the machine code differences will be specialized away. I'm pretty sure it's the Specification talk [2] that goes into the most detail about this. [0]: http://millcomputing.com/wiki/GenAsm_(code_representation) http://millcomputing.com/wiki/GenAsm_(code_representation) [1]: http://millcomputing.com/wiki/Specializer http://millcomputing.com/wiki/Specializer [2]: https://millcomputing.com/docs/specification/ https://millcomputing.com/docs/specification/
- chubot 9y ago
  There could be more ISAs than they have customers depending all on the needs in each case. But it's no big deal because everything targets GenAsm and the machine code differences will be specialized away Yeah so this is the point I'm quibbling with. I have no doubt it's technically possible. I'm saying that it will hinder adoption, and they're probably underestimating the diversity of software components that generate native code, and underestimating the cost of modifying all those components. Something like Xen succeeded because it designed up front to be a trivial modification to kernels -- i.e. paravirtualization. This sounds like a whole new architectural element. They're not only changing the interface between the CPU and the compiler; they're also changing the relationship between the kernel and the CPU (aside from there being a different ISA.) It's good to test assumptions, and I wish them luck. But after being somewhat excited about it, I feel it's just too ambitious. I'd love to be proven wrong though.
  - infogulch 9y ago
    To be clear, I'm just a random that's been following the mill project for a while, so please don't take my answers as gospel. The mill is a new, novel, ISA, which will require compilers to support it as a target. There's no getting around that. But once the tooling is ready, typical programs written in high level languages like C (i.e. excluding inline assembly and architecture-specific assumptions) will be a compiler flag away from being able to distribute binaries that run on all mill chips. If it's the specializer you're concerned about, it's intended to be very transparent to the typical user, integrated into the system. Most users are completely unaware that a thing called the linker even exists, this should be similar. By the way, just building the spec (defines belt size, available instructions, etc) generates a fully functioning specializer for that machine. I'm pretty sure it does that today.
- benchaney 9y ago
  This doesn't seem like a huge deal to me. When you get down to it, there are a ton of different optional x86-64 extensions. Most packages target the simplest subset (No sse for 32-bit only sse2 for 64-bit). At the end of the day this is basically the same thing.

by chubot 9y ago

Symmetry 9y ago

I think what is supposed to happen is that the JITS generated general assembly for the whole Mill family which then goes through the standard specializer program to work with the particular model. But you're right that changing the hardware/software boundary is really complicated and I expect that to succeed the Mill will have to spend a lot of time incubating in some sort of high end embedded role before the ecosystem needed for a general purpose application processor is there. So things like network switches, cell towers, robots, etc. The sort of thing where you might already be running Linux on top of some sort of RTOS.

infogulch 9y ago

> Every single JIT compiler has to know about 4 ISAs? Actually it's way worse, but much better. Better first: Typically, binary programs targeting the mill don't target a specific machine, but they target a hypothetical "general mill" machine code called GenAsm [0]. GenAsm makes some generous assumptions about the hardware, like infinite belt and presence of machine instructions. Included with each machine is the Specializer [1], a program that takes GenAsm and converts it down to the specialized binary encoding for this specific machine; think of it like a linker. This includes translating infinite belt semantics into finite belts, polyfilling any missing machine instructions with microcode, etc, etc. This process is very fast and the OS can cache the result. JITs can use an API to convert generated GenAsm into runnable machine code which includes running it through the Specializer. The specializer is built along with all the other tooling based on the specification that Ivan mentioned briefly. Now for worse: because mill machines are specification-driven, there could be many more than just 4 ISAs. There could be more ISAs than they have customers depending all on the needs in each case. But it's no big deal because everything targets GenAsm and the machine code differences will be specialized away. I'm pretty sure it's the Specification talk [2] that goes into the most detail about this. [0]: http://millcomputing.com/wiki/GenAsm_(code_representation) http://millcomputing.com/wiki/GenAsm_(code_representation) [1]: http://millcomputing.com/wiki/Specializer http://millcomputing.com/wiki/Specializer [2]: https://millcomputing.com/docs/specification/ https://millcomputing.com/docs/specification/

chubot 9y ago
There could be more ISAs than they have customers depending all on the needs in each case. But it's no big deal because everything targets GenAsm and the machine code differences will be specialized away Yeah so this is the point I'm quibbling with. I have no doubt it's technically possible. I'm saying that it will hinder adoption, and they're probably underestimating the diversity of software components that generate native code, and underestimating the cost of modifying all those components. Something like Xen succeeded because it designed up front to be a trivial modification to kernels -- i.e. paravirtualization. This sounds like a whole new architectural element. They're not only changing the interface between the CPU and the compiler; they're also changing the relationship between the kernel and the CPU (aside from there being a different ISA.) It's good to test assumptions, and I wish them luck. But after being somewhat excited about it, I feel it's just too ambitious. I'd love to be proven wrong though.
- infogulch 9y ago
  To be clear, I'm just a random that's been following the mill project for a while, so please don't take my answers as gospel. The mill is a new, novel, ISA, which will require compilers to support it as a target. There's no getting around that. But once the tooling is ready, typical programs written in high level languages like C (i.e. excluding inline assembly and architecture-specific assumptions) will be a compiler flag away from being able to distribute binaries that run on all mill chips. If it's the specializer you're concerned about, it's intended to be very transparent to the typical user, integrated into the system. Most users are completely unaware that a thing called the linker even exists, this should be similar. By the way, just building the spec (defines belt size, available instructions, etc) generates a fully functioning specializer for that machine. I'm pretty sure it does that today.
benchaney 9y ago
This doesn't seem like a huge deal to me. When you get down to it, there are a ton of different optional x86-64 extensions. Most packages target the simplest subset (No sse for 32-bit only sse2 for 64-bit). At the end of the day this is basically the same thing.