I’ve been thinking a bit about exceptions, as there are so many cases where these exceptions can happen. Exceptions transfer the burden of unexpected cases from software to hardware. In the same way that RISC-V moved the default FP exception behavior to enforce checks in software to simplify the hardware design, I wonder if it might be possible to do the same thing with capabilities. In fact, since updating / changing / sharing / destroying capabilities has the potential to be a rare event, why have the cost for checking for exceptions in the hardware all of the time?
One possible solution is a future version which allows for an exception-free implementation, but that requires additional checks for many instructions. This could help with handling the perception that capability hardware is complex. The result of these operations could report an error in the same way that FP systems report errors, accumulating them in status registers until verified.
More work would be needed to evaluate the potential hardware and software benefits of a technique like this, but it could benefit small, area-minimal implementations.
I’ve been thinking a bit about exceptions, as there are so many cases where these exceptions can happen. Exceptions transfer the burden of unexpected cases from software to hardware. In the same way that RISC-V moved the default FP exception behavior to enforce checks in software to simplify the hardware design, I wonder if it might be possible to do the same thing with capabilities. In fact, since updating / changing / sharing / destroying capabilities has the potential to be a rare event, why have the cost for checking for exceptions in the hardware all of the time?
One possible solution is a future version which allows for an exception-free implementation, but that requires additional checks for many instructions. This could help with handling the perception that capability hardware is complex. The result of these operations could report an error in the same way that FP systems report errors, accumulating them in status registers until verified.
More work would be needed to evaluate the potential hardware and software benefits of a technique like this, but it could benefit small, area-minimal implementations.