Add a try ... catch construct

CoreDSL currently has no notion of actions which can fail, whereas in the physical systems CoreDSL aims to model, these actions can indeed fail. The most prominent example for this are standard memory accesses.

For ETISS, I implemented an error handling mechanism with utilizing existing CoreDSL functionality. The one big downside of this mechanism is its intransparency, error handling is done at a completely different location than the actual action which can cause an error.

A try ... catch construct would solve these issues in the grammar, allowing very easy description of a block of code that can fail, and what to do if it does fail:

instruction ins1 {
    ...
    behavior: {
        unsigned<XLEN> res = 0;
        try {
            unsigned<XLEN> offset = X[rs1] + imm;
            res = MEM[offset];
            MEM[offset] = X[rs2];
        } catch (MemoryWriteError) {
            cpu_exception_entry(0, RV_STORE_ACCESS);
        } catch (MemoryStorePageFault) {
            cpu_exception_entry(0, RV_STORE_PAGE_FAULT);
        } finally {
            X[rd] = res;
        }
    }
}

This issue is mainly meant to be a collection of ideas of whether this idea is feasible, and if so, how could it be implemented in the grammar.

Questions that immediately come to mind:

Where are possible exceptions declared?
Which actions can raise an exception?
What happens on uncaught but fatal exceptions?
Do we need/want finally / else blocks?

Minres / CoreDSL

Add a try ... catch construct #55