Re: Implementing Exception Handling in a VM

"Mark Andrews (The Other One)" <first.last@orcon.net.nz> wrote:


> Some time ago I wrote a simple Pascal-like language that ran on an
> equally simple VM--all implemented in Delphi.


I'm presuming your VM is of the very simple, "while not Terminated do /
case op of / opAdd: ... end" etc.


> I'd like to update the
> language to use exception handling constructs such as try-except-end and
> try-finally-end.
>
> Given that the implementing language (Delphi, in this case) has SEH, can
> I leverage this fact to add exception support in my Pascal-like
> language? If so, where might I learn how to do this?


That depends on whether or not you've implemented procedure calls in
your VM as Delphi procedure calls or as an explicit call stack. In other
words, does the function, in which your VM interpreter loop resides,
recurse? If it does, then you can use SEH via Delphi's exceptions;
otherwise, you can implement exception handling in the interpreter loop.


Actual real live SEH is done by having the native compiler embed
exception data in the CPU stack. Unless your VM is quite sophisticated,
you won't be dealing with it directly.


To get an interpreter working using Delphi itself for exceptions, it
would probably be easiest to recurse into the interpreter for the
'try..finally' and 'try..except' protected parts of your language. That
is, the point where the recursion call is made would be protected with a
Delphi try/except, and when exiting an exception block protected scope
in your language, you'd return in your interpreter.


Doing it manually in the interpreter loop: the way you do it depends on
what you want, but it basically involves walking up the call stack. If
you want a debugger to pick up on unhandled exceptions, you've should
probably do two walks: once to look for handlers until you find one, and
then walk the stack again and free up all the stack frames including all
locals (important if you've got C++ destructor-like semantics on any of
your types) and execute 'finally' blocks (unwinding). Once your done
with that and you've gotten the handler from the first walk, you simply
set up your machine to execute inside it. If you don't need the debugger
support, you can just do one walk that does both.


This means that your call stack needs to have a stack of exception
information (i.e. handlers) associated with it somehow. You could put
the exception info inside the call stack, in whatever structure you use
for activation records (i.e. stack frames). Your 'try' statements need
to compile into an instruction(s) which push handler info onto this
stack, and you need to pop off that info for both the normal,
no-exception route and the unwinding code.


The two-walk approach described above is basically the way that both
.NET and Win32 SEH work, AFAIK, in order to get good debugger support.
If it unwound while searching for a handler, you wouldn't be able to
inspect the function context at the point where an unhandled exception
was thrown.


-- Barry


--
http://barrkel.blogspot.com/

Return to the comp.compilers page.
Search the comp.compilers archives again.