- mitchParticipantApril 24, 2014 at 11:50 amPost count: 1
It seems that a lot of performance is gained by exposing the pipeline latencies and having the compiler statically schedule based on this. However, as new implementations of the Mill ISA are produced, the code will not be compatible between them. The ISA is not abstract – it depends on implementation details. Is there any concern over this?
- Ivan GodardKeymasterApril 24, 2014 at 1:33 pmPost count: 687
Mill code is member-dependent at the encoded bit level. In fact, it is even slot-dependent: the exact same add operation encodes differently if it is the first, second, or Nth operation in an instruction (usually, anyway, depending on what operations are supported in the different slots). Because operations that are not present cannot be encoded, the Mill encoding is very dense and compact,
However, Mill code is member-independent at the load-module level. Compiler output does express an abstract form of the program, just as you suggest. That abstract code is then specialized to the concrete binary of the actual Mill member, and the specialized code is than cached back into the load module so that specialization only need be done once per different Mill that will run on.
Typically code is specialized at install-time, although it may be done at load time or (to build ROMs and a few other purposes) as a manual command. Specialization is very fast, because its job is roughly what is done in the backend of a conventional compiler. A few other tools that work with concrete binaries also are bit-level Mill dependent (a debugger for example) so we’ve put the concrete-to-abstract and abstract-to-concrete conversion functions in a library for application use if desired.
You must be logged in to reply to this topic.