[ISSUE-29] IRQ handlers with no conditional branching #37
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I know @Lurk PRed his fix for #29 and it was approved, but this is suggestion how to avoid conditional branching in the interrupt handler. It doesn't panic if the handler is already set yet, but can be added.
You may like it or not, I don't mind if you reject this PR.
Coming from the embedded work first thing that struck me was how to make interrupt handler as efficient as possible; I have even rough idea how to avoid
Box<>
in the array, but that's more work I don't have time for at the moment: we could only keep array of references to trait implementation, and static instances holding particular interrupt handler - if done right it wouldn't even need to panic, assuming IRQ# assignment at compile time is acceptable for all cases.