Basic Analysis Framework + Elaboration

[AtomCrafty]

This PR marks the start of a new analysis implementation. It lives in com.minres.coredsl.analysis and my plan is to eventually replace all of the existing analysis facilities, including the TypeProvider and CoreDslInterpreter.

Even though it is still a draft, the elaboration is mostly functional and can be tested by running the IDE project.

Architecture

All of the analyzers are static classes, meaning they cannot be instantiated and provide their functionality through static methods. Because of this they cannot store any state, which is why they are passed an AnalysisContext or ElaborationContext for every operation.

Analysis Context

Full path: com.minres.coredsl.analysis.AnalysisContext Replaces: nothing

Reponsibilities:

• Holding state of global analysis operations

Elaboration Context

Full path: com.minres.coredsl.analysis.ElaborationContext Replaces: com.minres.coredsl.interpreter.EvaluationContext

Reponsibilities:

• Holding state of per-core analysis operations
• Providing an interface through which errors and warnings can be reported
  • Note: errors should only ever be reported on nodes within the lexical scope of the analysis root

The difference between the analysis context and the elaboration context is that the elaboration context is specific to each elaboration root ISA. Whenever logic inside of an ISA is analyzed, the elaboration context is needed to determine which core definition (or instruction set in case of partial elaboration) is being elaborated. For static analysis that is only performed once instead of for each core, the analysis context is used.

Type Classes

Full path: com.minres.coredsl.type.* Replaces: com.minres.coredsl.typing.DataType

Reponsibilities:

• Representing types of variables within CoreDSL descriptions
• Special ErrorType to signal errors during type resolution
  • ErrorType.invalid - an unrecoverable error occured during type analysis (for example violated type rules)
  • ErrorType.indeterminate - the type can not be determined because it depends on unassigned constants
• Separate classes for type categories
• is{*}Type helpers

Constant Value Class

Full path: com.minres.coredsl.analysis.ConstantValue Replaces: com.minres.coredsl.interpreter.Value

Reponsibilities:

• Representing the value of a constant expression
• Special constants
  • ConstantValue.invalid - the expression is not a constant or can not be evaluated
  • ConstantValue.indeterminate - the expression can not be evaluated because it depends on another unresolved value

Type Provider

Full path: com.minres.coredsl.analysis.CoreDslTypeProvider Replaces: com.minres.coredsl.typing.TypeProvider

Reponsibilities:

• Determining the type specified by TypeSpecifier nodes (getSpecifiedType)
• Determining the static type of Expression nodes (not implemented)

Important methods:

• CoreDslType getSpecifiedType(ElaborationContext ctx, TypeSpecifier specifier)

Related classes:

• ElaborationContext - to look up the type of identifiers
• CoreDslConstantExpressionEvaluator - to determine the value of integer size specifiers

Constant Expression Evaluator

Full path: com.minres.coredsl.analysis.CoreDslConstantExpressionEvaluator Replaces: com.minres.coredsl.interpreter.CoreDslInterpreter

Reponsibilities:

• Determining the value of compile-time constant expressions

Important methods:

• ConstantValue evaluate(ElaborationContext ctx, Expression expression)

Related classes:

• ElaborationContext - to look up the value of ISA constants
• CoreDslTypeProvider - to resolve the types used within sizeof and bitsizeof expressions

Elaborator

Full path: com.minres.coredsl.analysis.CoreDslElaborator Replaces: nothing

Reponsibilities:

• Resolving the values and types of ISA constants
• Merging constant declarations across instruction sets

Important methods:

• ElaborationContext elaborate(AnalysisContext actx, ISA isa)

Related classes:

• ElaborationContext - holds state
• CoreDslConstantExpressionEvaluator - to determine the value of ISA constants
• CoreDslTypeProvider - to determine the type of ISA constants

Analyzer

Full path: com.minres.coredsl.analysis.CoreDslAnalyzer Replaces: nothing

Reponsibilities:

• Tieing together all of the other analyzers (not implemented)
• Providing an interface to the outside (not implemented)

[AtomCrafty]

@jopperm @eyck

The remaining failing test cases all depend on this file: https://github.com/Minres/RISCV_ISA_CoreDSL/blob/master/RISCVBase.core_desc

The issue is that it declares several aliases, which are not marked as register or extern. All ISA state declarations without an explicit storage class currently default to the storage class param and ISA parameters may not be declared as an alias or array.

I see two ways of handling this issue: Enforcing an explicit storage class specifier or making all alias declarations default to a different storage class. I prefer the first approach. The second one is flawed, because alias-ness is a property of the declarator, while the storage class is a property of the declaration as a whole. So a declaration with both an alias and a non-alias declarator would no longer have a well-defined storage class:

unsigned int x = 5, &alias = PC;

[eyck]

Well, an alias itself does not have a storage class as it is another name for a variable and as such inherits the storage class. It is an error if the type of an alias is not the same as the original variable.

[jopperm]

Hmm, the alias thing is interesting. My first hunch also is that we shouldn't have to repeat the storage class on the alias. An alias is a declaration with an ampersand in it, so that should suffice to mark it as an alias, and in consequence, inherit the storage class from the entity it points to.

However, the same reasoning could then also be applied to the type specifier. On the other hand, I wanted to make it possible to change the constness and volatileness of an alias (e.g. to have a read-only alias to some writable entity).

[AtomCrafty]

I guess we could sidestep the alias issue by not allowing mixed declarations. Then we could introduce a new alias storage class and in case no explicit storage class is specified, we default to either param or alias depending on the declarators:

int a, b;           // implicit storage class "param"
int &x = a, &y = b; // implicit storage class "alias"
int p, &q = b;      // error, mixed declaration

[jopperm]

I guess we could sidestep the alias issue by not allowing mixed declarations. Then we could introduce a new alias storage class and in case no explicit storage class is specified, we default to either param or alias depending on the declarators:

int a, b;           // implicit storage class "param"
int &x = a, &y = b; // implicit storage class "alias"
int p, &q = b;      // error, mixed declaration

Yes, that SGTM! (minus adding an alias keyword, cf. the thread above)

[AtomCrafty]

Ready for review. @jopperm Could you please add the table from https://github.com/Minres/CoreDSL/pull/59#discussion_r973708842 or a variation thereof to the spec?

Also I have no clue why the CI is failing. All tests are successful on my end. The errors reported by the pipeline are complete nonsense and refer to line numbers that don't even exist.

[AtomCrafty]

The ProxyMessageAcceptor class is used to automatically report errors in the correct place. If during elaboration of a core, an issue is reported within a provided instruction set, the proxy acceptor will report that issue on the core's name token. It also prevents us from accidentally reporting issues in other source files, which would cause the validator to crash.

[eyck]

Well, the gradle test reports about the Java lines but you are looking at the xtend sources therefore they don't match.

[jopperm]

@jopperm Could you please add the table from #59 (comment) or a variation thereof to the spec?

Will do!

[jopperm]

Done: diff

[jopperm]

I also made the change that only parameter declaration are merged: diff