5 ms·

> 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 do

> 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.
- reitzensteinm 9y ago
  I don't think that's a good comparison. Feature flags are added every couple of years on x86, but it's fairly linear. It's more analogous to something like CUDA, where the you are completely abstracted away from the actual assembly that's running on the GPU. Or like targeting LLVM bitcode.
  - benchaney 9y ago
    How is it abstracted away from the actual assembly? Sure, you don't know how large the belt is, but you can just use the smallest size. The entire point of the belt is that the overwhelming majority of the time you only need the front few elements. The other major difference is the presence of extra special purpose instructions. That is exactly what feature flags are primarily used for.
    - reitzensteinm 9y ago
      The amount and type of execution units will also impact the translation. Each mill cpu has a custom encoding format generated to match its resources. x86 has essentially a bidirectional 1:1 mapping between the assembly and the bytes directly executed by the cpu. The mill does not have that.

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.

reitzensteinm 9y ago
I don't think that's a good comparison. Feature flags are added every couple of years on x86, but it's fairly linear. It's more analogous to something like CUDA, where the you are completely abstracted away from the actual assembly that's running on the GPU. Or like targeting LLVM bitcode.
- benchaney 9y ago
  How is it abstracted away from the actual assembly? Sure, you don't know how large the belt is, but you can just use the smallest size. The entire point of the belt is that the overwhelming majority of the time you only need the front few elements. The other major difference is the presence of extra special purpose instructions. That is exactly what feature flags are primarily used for.
  - reitzensteinm 9y ago
    The amount and type of execution units will also impact the translation. Each mill cpu has a custom encoding format generated to match its resources. x86 has essentially a bidirectional 1:1 mapping between the assembly and the bytes directly executed by the cpu. The mill does not have that.