Mill Computing, Inc. Forums The Mill Tools Compilers C semantics and the Mill Reply To: C semantics and the Mill

Ivan Godard
Keymaster
Post count: 689

We have thought a bit about how some Mill facilities could be reached using language extensions. We will of course supply an intrinsics library for all the Mill opset, but intrinsics are a poor medium for coding.

The Mill ability to return multiple results can be expressed in C++ using tuples, which may in time be adopted by C in some form. However, I personally find the C++ tuple syntax singularly unsatisfying. An alternative is to admit pass-by-copy for arguments, as exists in Ada and other languages in which function arguments may be marked as in, out, or inout. It would not be difficult for a compiler to implement out and inout arguments using multi-return. The notation should be much more convenient to use than picking tuples apart, while the execution should be more performant (and much safer) than using pointer or reference arguments.

Will mentions the Mill overflow behaviors. These are most naturally brought into C as type-qualifiers: “__saturating short a” and the like. However, there would need to be promotion rules and extensions to the type lattice to deal with mixed arithmetic.

There’s one thing you suggest that we cannot do, though. While the Mill operations are polymorphic at issue, they are not so at retire: the latency of (most) operations varies with the actual widths of the operands. Consequently it is not in general possible to write a function that is polymorphic over different types. Well, it can be done, sometimes, if you know exactly what you are doing – but the code will break on the next Mill member with a different timing matrix.

We do intend to extend our own C compiler (and others) to better support Millisms, and will put in proposals to the language committees for the extensions. Thereafter it’s up to the language mavens 🙂