Forum Replies Created

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • c3d
    Member
    Post count: 5
    in reply to: Pipelining #1407

    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 :-)

  • c3d
    Member
    Post count: 5
    in reply to: Execution #1393

    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?

  • c3d
    Member
    Post count: 5
    in reply to: Pipelining #1391

    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).

  • c3d
    Member
    Post count: 5
    in reply to: Pipelining #1405

    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.

  • c3d
    Member
    Post count: 5
    in reply to: Pipelining #1403

    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?

Viewing 5 posts - 1 through 5 (of 5 total)