[M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?

[Rodney M. Bates]

On 07/29/2015 11:36 PM, Jay K wrote:
> On the last point -- I'm willing to generate C++ instead of C. Does that help?
> I think it probably does.
>
>
> On Win32 I could still generate C. And, not important, but Ultrix, OSF/1, and OpenVMS I
> think all support what Win32 support -- not a coincidence..
>
>
> One thing I'm missing is I don't know really know how exceptions are lowered currently.
> Like, what does the runtime data look like for the "filtering".
> I should know better..
>
>
> I think we can also essentially claim all targets have a stack walker.
> One way or another -- libunwind, NT RtlUnwindEx, etc.

Really?  That would be great news.  If it really applies to them all, wouldn't
the jmpbuf problem just go away?

>
>
>   - Jay
>
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Subject: Re: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?
> From: hosking at purdue.edu
> Date: Thu, 30 Jul 2015 14:04:14 +1000
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I agree that lifting the abstraction level for exceptions in the front-end would be a good idea.
> It would allow us to more effectively make use of specialized target exception handling, e.g., from LLVM.
> That suggests we at least lift to the LLVM level of abstraction, but I don’t know how easy that will be to generate from for the C backend.
>
>     On Jul 30, 2015, at 10:38 AM, Jay K <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> wrote:
>
>     I don't have one precise proposal, but somehow,
>     jmpbuf/setjmp/longjmp should be represented in a higher level in m3cg
>     or maybe "even higher level", exception handling.
>
>
>     There are multiple optimization opportunties and multiple
>     opportunities to move/remove target-dependent code.
>
>
>
>     In particular m3middle/m3front should not know jmpbuf size.
>     Generated C should not have jmpbuf sizes embedded in it.
>
>
>     gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exception
>     handling, that llvm replicates, that is optimized, like to not
>     save/restore unused registers.
>
>
>     Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.
>
>
>     In particular, the C backend just wants to know something is a "jmpbuf"
>     so it can #include <setjmp.h> in the generated code and produce a
>     jmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.
>
>
>     Or even better, a C++ backend wants to somehow module Modula-3 exceptions
>     as C++ exceptions.
>
>
>     Or, possibly, the Win32 C backend could model Modula-3 exceptions using
>     "structured exception handling" -- advantage over C++ exceptions is portability
>     to kernel mode.
>
>
>     Thoughts?
>       - Jay
>
>
>     _______________________________________________
>     M3devel mailing list
>     M3devel at elegosoft.com <mailto:M3devel at elegosoft.com>
>     https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>
>
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org