Re: PreScheme exception handling

On Sat, Nov 21, 2015, at 10:57 AM, Michael Sperber wrote:
> 
> Thomas Hintz <[email protected]> writes:
> 
> > I'm attempting to use setjmp and longjmp with PreScheme to handle
> > exceptions. The problem is PreScheme pulls the result of the setjmp call
> > out of the if statement and instead stores its result in a variable
> > which the if statement then checks. For setjmp the call needs to be in
> > the if test itself or you get some wacky behavior (it would seem).
> 
> I suspect what you're trying to do is fundamentally incompatible with a
> lot of the optimizations performed by the C compiler, which assume there
> can't be non-local transfer of control.

More-or-less, yes. I believe at the lowest levels though it is an
accepted and often used pattern and if the variable is declared volatile
it should work fine with the C compiler.

All this makes me wonder, how does the PreScheme Scheme48 code handle
exceptional cases? I feel like it must do something like this somewhere
but a cursory look through the code didn't give me any good clues as to
how it handles exceptional cases. Is there some other pattern I'm
missing?

> I'd start by trying to declare the setjmp be a simple C primop.  Or did
> you already do that?

What do you mean by that? The actual use of setjmp can't be in its own
function. It _must_ be in the if test that branches to "try/catch" code.

I actually did figure out a way to make the whole thing work with some
"interesting" C macros but they still require the variables to be
declared volatile and the macros are far from hygenic.

Which brings me to another question, would it be difficult to add
support to the PreScheme compiler for inferring that a variable be
declared volatile? It turns out regardless of the setjmp/longjmp
situation I will need that for safely handling threads since that
requires some assembly code and the C compiler needs to know not to
optimize the related variables away.

Obviously I could move stuff like that into C but I would prefer
extending PreScheme to support it instead since I hope to eventually
support an assembly backend for PreScheme that wouldn't require a C
compiler. If it is only a tiny bit of C that would be acceptable though,
which I am investigating.

Thanks and all the best,
Thomas Hintz