branlwyd
commented
11 years ago For the step handler idea, could also introduce an "error step handler" used only in error situations that does nothing, to remove need to check error each time a step is taken.
Also, need to be careful about conditions for adding/removing the Interrupt step handler. It can also fail to handle an interrupt when the "skip" flag is set. Would need to take this into account.
For that matter, could also create a Skip step handler that handles the CPU's skip state. Would need to keep track of which state to go back to after skip finished.
Device notification through cyclesElapsed() can be factored out of the individual step handlers. (This would nicely also allow the debugger device to immediately get notification when an interrupt is received, breaking on the first instruction.)
A couple of performance ideas:
INTinstruction) or hardware. Software instructions are already interrupting from same thread. By refactoring hardware to only interrupt incyclesElapsed()we can ensure that all interrupts come from same thread.Experiment with "step handler." That is, create a StepHandler interface that handles a single step. Two stephandlers: one for instructions/regular execution, one for interrupt checking.
step()just calls the current step handler. Normally the instruction step handler is installed. On receiving an interrupt, or enabling interrupts (RFI/IAQinstructions), the interrupt step handler is installed instead. Once it has run, the interrupt step handler reinstalls the instruction step handler (as either it has handled an interrupt, and therefore interrupts are disabled; or it has discovered there are no interrupts to handle).Things to look out for with this: need to be careful this actually provides an increase in performance (balancing the extra level of indirection per step with the lack of needing to check for interrupts every step). Need to make sure existing code is okay with having 0 cycles returned from step() without assuming it's an error.