[M3devel] Areas that may need attention in the frontend?

Fri Sep 21 15:33:48 CEST 2012

I haven’t looked at what the front-end does with exception handlers in a long time.  I’ll try to look soon.  Let me know what you find out.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484

On Sep 20, 2012, at 4:37 PM, Jay K <jay.krell at cornell.edu> wrote:

> Eh. Better yet, I'll just pass an extra parameter to direct calls to exception handlers.
> It is a gross special case. The backend shouldn't know anything about these functions.
> 
> 
>     (* workaround frontend bug? *)
>     IF proc.is_exception_handler THEN
>         push(u, Type.Addr, "0");
>         pop_parameter_helper(u, "0");
>     END;
> 
> 
> Again though, I need to see what happens with the other backends.
> 
> 
> The other backends pass the static_link in a special way (do all calling
> conventions really have an extra, special register?), so that is part of their out.
> Plus that you can pass more parameters than are used.
> So they pass a static link in a special register, and one or zero parameters for the activation.
> The lingering question is what happens in finally blocks that access the activation but there isn't one.
> In my case it will be nil, with the above hack.
> For the other backends I think it is arbitrary garbage.
> 
> 
>   - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Thu, 20 Sep 2012 20:10:03 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Areas that may need attention in the frontend?
> 
> This is still bugging me. My current plan is that for exception handlers (functions that end _M3_LINE_number or I3), I will generate the "usual" function Foo, and the function FooDirect. I will set a field in my Proc variable pointing to "direct". Whenever I make a direct call, I'll call the direct function. When I take the address, e.g. for an indirect call, I'll call the "regular" one.
> The indirect version will take two parameters -- activation and static link, static link list, the direct one will take one, static link.
> 
> 
> I kind of think this a bug in the frontend.
> 
> 
> It might even be a bug with other backends.
> It is rare for a finally block to look at the exception that was raised.
> 
> 
> This only affects finally blocks.
> 
> 
> It doesn't affect except blocks.
> They aren't ever "separate little functions", but rather chunks of code entered/exited via goto.
> 
> 
> 
> I do need to investigate more though.
> 
> 
> Perhaps the frontend notices if a finally block calls Compiler.ThisException() and does something different?
> 
> 
> Inside a finally block, can I call a function, that itself calls Compiler.ThisException()? That would make it impossible for the frontend to fix up. Unless maybe it was pessimistic and observed any function call in a finally block as a sign to do things differently.
> 
> 
> Compiler.ThisException() is available in finally blocks, right?
> Otherwise the parameter would ever be passed (i.e. in RTExFrame.m3)
> 
> 
> The analog in Microsoft "SEH" isn't complete.
> A finally block can call BOOL AbnormalTermination() to find out if you "fell off the end" of the __try or called __leave, or raised an exception or returned. (return is kind of unfortunately "abnormal" -- and incurs runtime cost).
> But access to "the exception" is only available in __except filters and maybe __except blocks.
> Not __finally blocks.
> 
> 
> "All these Digital systems" and "all these exception handling systems" seem to have commom threads running through them, similar features, similar syntax, and similar implementation strategies. That's why I bring it up. 
> 
> 
>  - Jay
> 
> 
> Subject: Re: [M3devel] Areas that may need attention in the frontend?
> From: hosking at cs.purdue.edu
> Date: Thu, 20 Sep 2012 08:16:59 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> 
> 
> On Sep 20, 2012, at 7:37 AM, Jay K <jay.krell at cornell.edu> wrote:
> 
> I think this isn't right. I understand the static link is implied by level > 0. But the activation/exception parameter should be always passed or never passed. Or there should be two functions -- one that takes an exception, one that doesn't, and one calls the other. Or pass it as null if there isn't an exception.
> 
> I should really not have to resort to K&R and passing varying numbers of parameters.
> 
> I still have to look at a few test cases to see when each parameter is used.
> Maybe I'm confused.
> 
> The other thing, you want the code to stay?
> 
> For now, yes.
> 
> 
>  - Jay
> 
> 
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> From: jay.krell at cornell.edu
> Subject: Re: [M3devel] Areas that may need attention in the frontend?
> Date: Wed, 19 Sep 2012 21:33:43 -0700
> To: hosking at cs.purdue.edu
> 
> Clarification: the "questioning comment" is not mine, it is there in the code. I suspect it is a good question & that the code isn't what it should be.
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On Sep 19, 2012, at 7:39 PM, Antony Hosking <hosking at cs.purdue.edu> wrote:
> 
> On Sep 19, 2012, at 9:31 PM, Jay K <jay.krell at cornell.edu> wrote:
> 
> Areas that may need attention in the frontend?
> 
> 
> TryFinStmt.m3:
> 
>       CG.Start_call_direct (p.handler.cg_proc, p.handler.level, CG.Type.Void);
>       (* Shouldn't we pass the activation parameter here?
>          What value do we pass? *)
>       CG.Call_direct (p.handler.cg_proc, CG.Type.Void);
> 
> The level let’s you compute that.
> 
> I'm wondering this too...like..what is the interface
> to except/finally blocks?
> 
> ?
> 
> It appears they take two, or one, or zero parameters,
> depending on intepretation and context.
> 
> 
> two parameters:
>  _static_link
>  exception stuff
> 
>  
> one parameter:
>  _static_link
>  
> 
> zero parameters:
>  the above
> 
> 
> I think the right implmentation (assuming no significant
> change to nested functions, which Tony is thinking about:) )
> is one parameter:
> 
>   exception stuff
> 
> and the implied/popped static_link, always.
> 
> 
> For now, I think I'll not prototype these and use K&R definitions, yuck!
> 
> That works.
> 
> Maybe generating C++ with overloads is a good idea??
> 
> 
> 
> values/Procedure.m3:
> 
>     ELSIF (cur.token = TK.tSEMI) THEN
>       t.body := NEW (Body, self := t);
>       ProcBody.Push (t.body);
>       (* try accepting the Modula-2 syntax *)
>       Error.ID (id, "expecting \'=\' before procedure body");
> 
>  
> Probably everything after the error should be removed?
> Or this is an example trying to recover from parse errors
> and doing best effort?
> 
> Yes.
> 
> 
> 
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120921/c6954e96/attachment-0002.html>