On Mon, Mar 01, 2010 at 06:13:53AM -1000, Zachary Amsden wrote:
... you are broken. This case can be made very much more complexvolatile is a language keyword how it can be not implemented by the
and hard to reason about by using local variables which are reset by
the longjmp.
Further, it requires use of the volatile keyword to interact
properly with logic involving more than one variable, and thus, by
definition is impossible to use in the kernel, which does not
implement the volatile keyword. :)
kernel? And why volatile is needed to implement longjmp?
Instead, for this case, use the fact that there is anOf course it is possible to use return values instead. This is what code
architecturally designed finite number of exceptions that can be
processed simultaneously. This means if you queue exceptions to a
pending list of control-flow interrupting events to be processed, as
long as the queue is appropriately sized, you will never overflow
this queue and never require dynamic allocation. Further, you can
then naturally follow the exception priority rules at the top-level
of the emulator and never need to pass back complex exception
structures, merely a simple return value which indicates whether to
return to top-level control logic or continue with instruction
emulation. I believe using this style of programming will make your
need for setjmp/longjmp go away.
does currently and this is completely unrelated to exception queue
depth. Code will be much simpler if we will be able to bail out from the
depth of emulator immediately if exception condition is met or exit to
userspace is required instead of passing the condition up the call
chain.