Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a try ... catch construct #55

Open
wysiwyng opened this issue Jun 28, 2022 · 0 comments
Open

Add a try ... catch construct #55

wysiwyng opened this issue Jun 28, 2022 · 0 comments
Labels
enhancement New feature or request question Further information is requested
Milestone

Comments

@wysiwyng
Copy link

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?
@jopperm jopperm added enhancement New feature or request question Further information is requested labels Jun 28, 2022
@jopperm jopperm added this to the CoreDSL 2.1 (202x) milestone Nov 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants