ivan
In effect yes, though not really. The abstract form has no belt; it is a dataflow graph overlain with a control-flow graph. That is, it's not a P-code or Java code or any of the other serializations; there's no reason for the specializer to have to figure out the data dependencies that the compiler already knew but threw away in the intermediate representation.
Of course, it is trivial to go from the graphs to a serialized instruction stream with infinite belt, and we might even offer a command option to produce that, for those who find such a representation to be an easier way to understand what is going on. But it would only be documentation.
ivan
Exactly :-)
David
We're going to be rewriting the AOT and JIT compilers for the next version of our declarative programming server, so user code feeding the specializer is of particular interest to me, even if just for forward compatibility thinking.
At the location of a compiler backend, yes it is relatively equivalent to convert between graphs and LLVM-style virtual instructions. For compiler writers, it sounds like graph generation will be the expectation on the Mill? That could likely be a bit easier than instructions, thinking about it...
ivan
I hope so :-)
The LLVM middle-to-back representation is more a linearization than a serialization. We plan to back up into the middle end just a little and serialize the internal (graph) representation after all the regular passes and a few Mill-specific passes are done. The compiler-to-specializer representation knows it's a Mill but doesn't know which one.
jobol
Is there a plan for SIGNED divisions? The ainsi C specs for division of SIGNED are good but it exist an other kind of SIGNED division. When computing A/B and A%B, C say something like:
[1+abs(A/B)] * abs(B) > abs(A) >= abs(A/B) * abs(B)
But the euclidian division specify that
abs(B) > A%B >= 0
Then for C: -10/3=-3 and -10%3=-1
But for euclidian: -10/3=-4 and -10%3=2
If specification is "easy", do you intend to have 2 signed divisions?
note ** https://en.wikipedia.org/wiki/Euclidean_division#Examples
ivan
The Mill already defines signed division, but not in the sense you mean. DIVU accepts unsigned arguments and so the ambiguity for signed does not exist. DIVS accepts signed arguments and produces the C-language result, as is standard in the programming languages that the hardware must accept. We expect that division will be an emulated op (rather than hardware native) on nearly all Mill members. We define a reciprocal-approximation helper op to get the emulation started, and the helper will be native. In practice, the helper and software Newton/Rapheson of the emulation is nearly as fast as a hardware version would be.
It is easy to specify another operation, but it still must be implemented, tested, verified, and documented, and that is not without cost. Consequently we only add ops when their use can improve performance of widely used languages, or where they are needed by critical applications that will access them through intrinsics.
So far we know of no language or app that would justify another division. It is quite rare for an app to have division as a performance-critical step, but if you are aware of any then please bring them to our attention.