exception handlers & calling conventions

NAVIGATION

CATEGORIES

Perl

REFERRENCE

If you have some good idea, Cilck and mail to us please...

LINKS

Home » Perl

exception handlers & calling conventions
9 answers - 1103 bytes -
The last (and never done correctly) relict of old calling conventions
Technically an excpetion is kind of an object with some info (TD) and
the exception handler is a (limited) continuation:
pmclass Exception_Handler extends Continuation # see classes/
Throwing an exception is calling an exception handler and delivering
results. This is the same as invoking a continuation. See e.g.
t/op/calling_48.pir or t/op/lexicals_29.pir.
Which means that we need:
catch_label:
get_results "()", Pexcept, Smessage, # whatever
or in PIR speak, the left hand side of a sub call;
(ex, mess, ) = catch_label # the RHS is just a label or the
handler
(the left side - the results part - is that where continuations are
branching to - strange isn't it?)
And the opcode
push_eh catch_label
is creating the Exception_handler with the 'get_results' in it's
context, so that it can deliver results.
Just a brain dump before I forget it ;-)
Detailed syntax bits welcome
leo
No.1 | | 1184 bytes | |
Fri, Nov 25, 2005 at 11:45:40PM +0100, Leopold Toetsch wrote:
Technically an excpetion is kind of an object with some info (TD) and
the exception handler is a (limited) continuation:

pmclass Exception_Handler extends Continuation # see classes/

Neat.

catch_label:
get_results "()", Pexcept, Smessage, # whatever

Right.

And the opcode
push_eh catch_label
is creating the Exception_handler with the 'get_results' in it's
context, so that it can deliver results.

Ah, interesting! And definitely a great way to implement the current
scheme. I have some thoughts about changing the current scheme, which
I'll mention in another message. Nothing impending, though.

Detailed syntax bits welcome

Let's see

# (a)
catch_label:
.results ($P0)

Not bad. Matches up with get_results. But the direction isn't
entirely clear when you read it: Is it setting or getting results?

# (b)
catch_label:
.get_results ($P0)

Better, I think.

# (c)
catch_label:
($P0) = @EXCEPTIN # or some other magic word

Ew. I still like (b).
No.2 | | 696 bytes | |
Chip Salzenberg wrote:
Fri, Nov 25, 2005 at 11:45:40PM +0100, Leopold Toetsch wrote:

>catch_label:
>get_results "()", Pexcept, Smessage, # whatever

This part is now implemented (r10241). (Funnily it did work immediately :)

Currently exactly these 2 arguments (exception, message) are passed

handler:
get_results "(0,0)", P0, S0

The get_results opcode has to be immediately after the exception handler
label.

For a certain transition phase P5 is still containing the exception PMC.

Syntactic sugar, a la

# (b)
catch_label:
.get_results ($P0)

will follow soon.

leo
No.3 | | 1011 bytes | |
Nov 29, 2005, at 8:38 AM, Leopold Toetsch wrote:

Chip Salzenberg wrote:
>Fri, Nov 25, 2005 at 11:45:40PM +0100, Leopold Toetsch wrote:
>
catch_label:
get_results "()", Pexcept, Smessage, # whatever

This part is now implemented (r10241). (Funnily it did work
immediately :)

Currently exactly these 2 arguments (exception, message) are passed

handler:
get_results "(0,0)", P0, S0

Currently, partcl stores extra information in P5[9] - Would it be
available as P0[9] in your example? (If so, is the message still
available as P0[0] ? If so, why do we specify S0 here?)

The get_results opcode has to be immediately after the exception
handler label.

For a certain transition phase P5 is still containing the exception
PMC.

Syntactic sugar, a la
>
># (b)
>catch_label:
>.get_results ($P0)
>
will follow soon.

leo
--
No.4 | | 754 bytes | |
Will Coleda wrote:

Nov 29, 2005, at 8:38 AM, Leopold Toetsch wrote:

>handler:
>get_results "(0,0)", P0, S0

Currently, partcl stores extra information in P5[9] - Would it be
available as P0[9] in your example? (If so, is the message still
available as P0[0] ?

Sure. Nothing has changed in the layout of the Exception object. I've
described and implemented argument passing to exception handlers.

If so, why do we specify S0 here?)

Just for convenience. Named argument syntax would really simplify the
task. The exception handler could just specify, what it wants, e.g.:

handler:
get_results "()", "exception": P2, "arg9": Icoke

leo
No.5 | | 358 bytes | |
Leopold Toetsch wrote:

Syntactic sugar,

Done - r10243. Again exactly 2 arguments are supported for now:

handler:
.local pmc e
.local string mess
.get_results (e, mess)

Variable decls after the handler label aren't instructions and therefore ok.

See also t/pmc/exception.t /get_result

leo
No.6 | | 495 bytes | |
Nov 29, 2005, at 8:38 AM, Leopold Toetsch wrote:

Chip Salzenberg wrote:
>Fri, Nov 25, 2005 at 11:45:40PM +0100, Leopold Toetsch wrote:
>
catch_label:
get_results "()", Pexcept, Smessage, # whatever

This part is now implemented (r10241). (Funnily it did work
immediately :)

Again, after some patches by Leo for parrot and me for Tcl, partcl is
now using the new exception handling, passing 100%.

Regards.
No.7 | | 904 bytes | |
Tue, Nov 29, 2005 at 04:26:09PM +0100, Leopold Toetsch wrote:
Coke:
>If so, why do we specify S0 here?)

Just for convenience.

I appreciate the convenience argument, but given the ease of keyed
access, $P0[0] is pretty darned convenient already. And someday we
may want to pass things that are more than convenience. So I'd like
the signature of exceptions to just be (P), at least for now.

Which gives me an idea for PDD03: "IGNRE". Currently there's no way
to do the old Perl 5 thing of knowing that the caller passed more than
N arguments but you really only want N. How about:

exception:
.local pmc except
.param except
.param $P0 :slurp :ignore # don't bother constructing Array
if_null $P0, always # it's always Null

Hm. Seems like a pretty ugly kludge for a rare case.
No.8 | | 575 bytes | |
Nov 25, 2005, at 23:45, Leopold Toetsch wrote:

The last (and never done correctly) relict of old calling
conventions

is gone now. Please consult docs/compiler_faq.pod or this thread
for using get_results instead.

From r10257

Exception handler code: P5 is gone

The compat code caused more pain than it was worth. If you need it
for retesting please enable 2 lines labeled /* CMPAT: */
in exception_handler.pmc. Also fixed 2 remaining tests.

All hacks referencing P5 or such are not needed anymore.

leo
No.9 | | 196 bytes | |
>If so, why do we specify S0 here?)
Just for convenience.
In most places, I don't use the string. I'd rather just get the PMC.
Regards,
Roger Browne

Re: exception handlers & calling conventions

EMSDN.COM

Question 'exception handlers & calling conventions' on 'Perl'

Perl

exception handlers & calling conventions