Currently any "unexpected" situation inside the VM (division by zero, PC address out of range etc) puts it into the Break state. This is convenient for a software VM but unrealistic for a hardware one. For some events, an exception handling mechanism can be used to give target software a chance to correct the state.
The task is to design and implement the exception handling mechanism:
Add a separate return stack to store the PC of instruction that caused a problem.
Define what method of communication for enumerating interruption events should be used (on stack? in register? by indexing the ISR address?).
Define where interrupt routines are placed in the program memory
Add a new instruction ret to pop PC from return stack
Add new instructions to move data between return and data stacks (to be able to manipulate PC)
Add tests
Ultimately, the ISR should be capable to detect what particular interrupt happened and to correct it by either changing data state and/or emulating the instruction and skipping it in the original flow.
Currently any "unexpected" situation inside the VM (division by zero, PC address out of range etc) puts it into the Break state. This is convenient for a software VM but unrealistic for a hardware one. For some events, an exception handling mechanism can be used to give target software a chance to correct the state.
The task is to design and implement the exception handling mechanism:
ret
to pop PC from return stackUltimately, the ISR should be capable to detect what particular interrupt happened and to correct it by either changing data state and/or emulating the instruction and skipping it in the original flow.