c3d

@deepblue I agree with Ivan that there are things that are quite different that require brand new infrastructure to emulate the Mill correctly. For one thing, all the wide ISAs emulated so far are not really in the mainstream qemu support. Support for the most mainstream of them, Itanium, was dropped back in 2017. All the existing platforms also assume a rather classical register file, not a belt with configurable size and so on. So yes, this is going to be a lot of work in my opinion, not a student’s work for one year.

My point is really that providing a library that does that seems like a solution past the “committee hell” that Ivan was talking about. You first create a C++ library that implements the semantics you want. And once this gets adopted and used widely, the C++ standard committee takes it and integrates it into the language. Probably with slight and subtle incompatibilities

What is the maximum arity of operations on the Mill today? What impact does this maximum arity have on the other sizing factors (e.g. size of the belt, rotation, etc)? Do you for example have equivalents to the Itanium extract and deposit instructions?

Answering one of the last questions, you explain a proposal for saturated arithmetic that requires adding a keyword and treating it specially. What would be wrong with using a C++ class with overloaded arithmetic operators that encapsulates the intrinsics you need? That would solve issues such as integer + saturated, since the C++ language already has rules for that (that you might not like, but at least they exist).

First, just curious why you’d need literals? How is the binary representation of a 64 saturating int different from a 64 int?

Second, C++ operator overloading lets you deal correctly with X+Y, X+1 and 1+X. The only case missing is 1+1, and at least for saturation, the cases where it matters are few and can be spelled out explicitly e.g. with sat64(1)+sat64(1).

Finally, C++11 introduced user-defined literals which are I believe almost exactly what you ask for, see http://en.cppreference.com/w/cpp/language/user_literal.

The compiler will still have to recognise it for what it is in order to know to use the Mill’s saturating opcodes in the emitted binary.

My suggestion was to use intrinsics for that part. Something like:

struct sat64 {
   sat64(u64 x): value(x) {}
   sat64(i64 x): value(x) {}
   sat64 &operator += (sat64 o) { value = __mill_sat64_add(value, o.value); }
   ...
private:
   u64 value;
};

No need of anything special for the compiler.

Regarding the comment that programs are written in C: are they written in C that is so bad that it won’t compile with a C++ compiler?