Re: spurious assembleur directives get in the way of oneliner return implementation
Matt Diephouse
> Hi,
>
> Juste like I added the possibility of declaring many registers
> variables with one .sym directive, I am working on returning or
> yielding in one line so one can write:
>
> .return -1, name
>
> instead of:
>
> .pcc_begin_return
> .return -1
> .return name
> .pcc_end_return
<snip>
>
> Comments?
Yes, please! .pcc_begin_return/.pcc_end_return is so ugly. (And yes, I
realize this is PIR and not Perl.)
--
matt
Dan Sugalski
I'd be OK with this as well, though I think I'd make the token:
.return( .... )
so it could be relatively easily distinguished
from plain .return statements by the parser.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> .return -1, name
> Sadly, the .return directive and other are overloaded to express
> user stack operations.
> | PARAM reg { $$ = MK_I(interp, cur_unit, "restore", 1, $2); }
> | RESULT var { $$ = MK_I(interp, cur_unit, "restore", 1, $2); }
> | ARG var { $$ = MK_I(interp, cur_unit, "save", 1, $2); }
> | RETURN var { $$ = MK_I(interp, cur_unit, "save", 1, $2); }
Yes, this dual meaning of these directive is a PITA. E.g. the usage of
C<.param> is the reason that:
.sub foo
# get args
.param int bar
isn't parsed correctly. So I'd like to get rid of that the sooner the
better.
But, as you said, it might be used. So I'd propose:
- deprecate the usage of these directives for stack calling conventions
- for now, we go with Dan's syntax:
.return( list ) # a different token
.yield( list ) # same syntax
.yield list # pas de problem
> --
> stef
leo