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

[Jay K]

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 interfaceto 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 significantchange 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 errorsand doing best effort?
Yes.


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120920/4db07865/attachment-0002.html>