Type validation of instruction sets

[AtomCrafty]

I've pondered our options for the architecture of our program validator again, and one issue is that type correctness of an instruction set is generally undecidable without knowing its concrete instantiation.

Consider the following, very simple scenario:

A.core_desc

InstructionSet Base {
    architectural_state {
        int XLEN;
        unsigned<XLEN> x;
    }
}

B.core_desc

import "A.core_desc"

Core Derived provides Base {
    architectural_state {
        XLEN = -1;
    }
}

Obviously this results in a type error, because Base now contains a field of type unsigned<-1>, which is not a valid type. This can however only be discovered during validation of Derived.

My question would be how errors of this kind should be handled. The closest real world counterpart to this kind of parametrization I can think of would be C++ templates, and those are notorious for their incomprehensible error reporting.

• Are the errors reported at the correct position within the instruction set?
• Are all errors reported on the "provides Base" clause? Maybe with a prefix like "Error during instantiation of Base"?
• What happens if the instruction set is located in a different file?

Another question would be how to handle validation of individual instruction sets.

• Should we simply never validate instruction sets, but only core definitions?
• Should we partially validate instruction sets, but ignore everything involving unknown types?
• Should we attempt to infer constraints on the type somehow?

Has anyone thought about any of this during the language design phase? 😅

[jopperm]

My question would be how errors of this kind should be handled. The closest real world counterpart to this kind of parametrization I can think of would be C++ templates,

That is also my mental model.

and those are notorious for their incomprehensible error reporting.

Yup.

• Are the errors reported at the correct position within the instruction set?
• Are all errors reported on the "provides Base" clause? Maybe with a prefix like "Error during instantiation of Base"?

Maybe both, if that's possible? At some point, you're elaborating the CoreDefinition by traversing its provides clause, and trigger a full check of the referenced Instruction sets, during which you detected invalid types etc.

• What happens if the instruction set is located in a different file?

Aren't import'ed definitions all parsed into the same object model?

Another question would be how to handle validation of individual instruction sets.

I'd say

partially validate instruction sets, but ignore everything involving unknown types

... plus having default values for implementation parameters, as you proposed yesterday, would be useful. For future reference, your point was, basically all types are parametrised on XLEN, so assuming XLEN=32 would make vastly more declarations and assignments type-checkable.

[jopperm]

Closing this, AFAIK @AtomCrafty's latest version of the parameter elaboration and type checking phase does best-effort checking of instruction sets, and reports meaningfully-located errors.