Skip to content

Elaboration

Julian Oppermann edited this page May 22, 2022 · 15 revisions

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. Identical declarations (same name, type, dimensions, attributes) occurring in disjoint parts of the ISA hierarchy 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 between parameters must be detected and reported as errors.

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.

Clone this wiki locally