Elaboration

Each core definition undergoes an elaboration phase in which the combined architectural state and instruction set is determined.

Traversal order

A frontend shall walk the ISA hierarchy in topological order, honoring the order of the provides clause.

Example In the following situation,

                      ┌───────────────────┐
                      │ InstructionSet A  │
                      └───┬───────────┬───┘
                          │           │extends
                          │       ┌───┴───────────────┐
                          │       │ InstructionSet B  │
                          │       └───┬───────────┬───┘
                          │extends    │extends    │extends
                      ┌───┴───┐   ┌───┴───┐   ┌───┴───┐   ┌───────┐
                      │   C   │   │   D   │   │   E   │   │   F   │
┌──────────────┐      └───┬───┘   └───┬───┘   └───┬───┘   └───┬───┘
│ Core MyCore  │provides
│              │─ ─ ─ ─ ─ ┴ ─ ─ ─ ─ ─ ┴ ─ ─ ─ ─ ─ ┴ ─ ─ ─ ─ ─ ┘
│              │
└──────────────┘

the instruction sets and core definitions are considered in the order A, C, B, D, E, F, MyCore.

Composition of architectural state and user-defined types

The effective architectural state for a core definition is the superset of architectural state items from provided and local declarations. If parameters with the same name and type are declared in disjoint parts of the ISA hierarchy, these declarations are merged. Other than that, the names of architectural state items must be unique. The same rules hold for struct/union/enum type declarations inside the architectural state sections.

Evaluation of implementation parameters and register reset values

For each parameter/reset value in the combined architectural state of a Core, the last assignment is effective, according to the traversal order specified above and the source code order inside the sections. Assigments of implementation parameters in functions and instruction definitions are forbidden. Multiple passes may be required to reach a fixpoint. Cyclic dependencies are prohibited.

Example

InstructionSet A {
  architectural_state {
    int bits   = 128;
    int nelems =   4;
    int ewidth = bits/nelems; 
    register unsigned<ewidth> regA[nelems];
  }
}

InstructionSet B extends A { architectual_state { bits = 1024; }}

Core C provides A { architectual_state { nelems = 16; }}
Core D provides B {}

Here, Core C will have a register field with 16 elements of type unsigned<8>, whereas Core D contains a register field with 4 elements of type unsigned<256>.

Composition of instruction set

A core definition's instruction set is the combination of provided instruction sets and its local instructions section. Instructions may be redefined in this process; the last definition is effective, again according to the traversal order and the source code order inside the sections.

A frontend shall test the instruction encodings in the combined instruction set for collisions.