I don't see a way to do this at present. What I would like is an
equivalent to .flatten_arg for a PCC return, e.g.:
.pcc_begin_return
.flatten_arg array_of_results
.pcc_end_return
Of course, ".flatten_arg" sounds a bit odd in this context, so calling
it just ".flatten" might be better. (In which case it might be good to
support ".flatten" as a synonym for ".flatten_arg" in a PCC call.)
Is this on the right track?
-- Bob Rogers
http://rgrjr.dyndns.org/
Bob Rogers <rogers-perl6@no-spam> wrote:
> I don't see a way to do this at present. What I would like is an
> equivalent to .flatten_arg for a PCC return, e.g.:
> .pcc_begin_return
> .flatten_arg array_of_results
> .pcc_end_return
> Of course, ".flatten_arg" sounds a bit odd in this context, so calling
> it just ".flatten" might be better. (In which case it might be good to
> support ".flatten" as a synonym for ".flatten_arg" in a PCC call.)
> Is this on the right track?
Makes sense, yes. How many return values or arguments are flattened
usually?
leo
The attached patch is supposed to do two things:
1. Makes it possible to say ".flatten foo" as part of a
.pcc_begin_return/.pcc_end_return sequence. Remarkably, this part of
the patch is only a one-line change; the internals for call & return are
closer than the syntax.
2. Makes ".flatten" equivalent to ".flatten_arg" for all other
purposes, to emphasize the similarity.
Unfortunately, though this patch works as intended, it also has a
number of bizarre side-effects. Here's the summary of failing tests:
imcc/t/syn/macro.t 3 768 23 3 13.04% 11-12 23
t/op/string_cs.t 9 2304 28 9 32.14% 1-2 8 20 23-26 28
t/op/stringu.t 8 2048 14 8 57.14% 2-9
t/pmc/eval.t 1 256 9 1 11.11% 4
The imcc/t/syn/macro.t failures (the ones I understand, anyway) are
because it won't accept "ok" as a macro parameter name -- it thinks "ok"
is a USTRINGC and not an IDENTIFIER; the t/pmc/eval.t case seems to be
similar. The t/op/string_cs.t and t/op/stringu.t cases, on the other
hand, say
error:imcc:syntax error, unexpected LABEL
at every point where it scans a "unicode:" or "ascii:" prefix. FWIW,
all works well if I skip the lexer changes and just change pcc_return to
add "| FLATTEN target".
So clearly something is busted in the lexer. Either I made an error
(though that hardly seems likely, since the changes are so small), or I
didn't rebuild everything properly after changing imcc.y or imcc.l.
It's remotely conceivable that there's a bug in bison and/or flex (I'm
using the SuSE RPM versions bison-1.875-51.4 and flex-2.5.4a-293).
Or it could be that something else is busted. Unfortunately, I don't
have the expertise to nail it down, and am getting fed up after putting
in about 8 hours over the last five days. Is there a yacc guru out
there who could please give me a hint?
TIA,
-- Bob Rogers
http://rgrjr.dyndns.org/
Index: imcc/imcc.l
===================================================================
RCS file: /cvs/public/parrot/imcc/imcc.l,v
retrieving revision 1.124
diff -u -r1.124 imcc.l
--- imcc/imcc.l 28 Feb 2005 10:41:18 -0000 1.124
+++ imcc/imcc.l 21 Mar 2005 02:20:34 -0000
@@no-spam -193,6 +193,7 @@no-spam
".sym" return(LOCAL);
".arg" return(ARG);
+".flatten" return(FLATTEN);
".flatten_arg" return(FLATTEN_ARG);
".sub" return(SUB);
".end" return(ESUB);
Index: imcc/imcc.y
===================================================================
RCS file: /cvs/public/parrot/imcc/imcc.y,v
retrieving revision 1.154
diff -u -r1.154 imcc.y
--- imcc/imcc.y 30 Nov 2004 09:35:10 -0000 1.154
+++ imcc/imcc.y 21 Mar 2005 02:20:35 -0000
@@no-spam -332,7 +332,7 @@no-spam
%nonassoc <t> PARAM
%token <t> PRAGMA
-%token <t> CALL GOTO ARG FLATTEN_ARG IF UNLESS END SAVEALL RESTOREALL
+%token <t> CALL GOTO ARG FLATTEN_ARG FLATTEN IF UNLESS END SAVEALL RESTOREALL
%token <t> NEW NEWSUB NEWCLOSURE NEWCOR NEWCONT
%token <t> NAMESPACE ENDNAMESPACE CLASS ENDCLASS FIELD DOT_METHOD
%token <t> SUB SYM LOCAL CONST
@@no-spam -719,6 +719,9 @@no-spam
pcc_arg:
ARG var { $$ = $2; }
+ | FLATTEN target { $2->type |= VT_FLATTEN; $$ = $2; }
+ /* .flatten is preferred, for symmetry with pcc_return, but .flatten_arg is
+ accepted for backwards compatibility. */
| FLATTEN_ARG target { $2->type |= VT_FLATTEN; $$ = $2; }
;
@@no-spam -765,6 +768,7 @@no-spam
pcc_return:
RETURN var { $$ = $2; }
+ | FLATTEN target { $2->type |= VT_FLATTEN; $$ = $2; }
;
pcc_return_many:
@@no-spam -1088,6 +1092,9 @@no-spam
arg:
var
{ $$ = $1; }
+ | FLATTEN target { $2->type |= VT_FLATTEN; $$ = $2; }
+ /* .flatten is preferred, for symmetry with pcc_return, but .flatten_arg is
+ accepted for backwards compatibility. */
| FLATTEN_ARG target
{ $2->type |= VT_FLATTEN; $$ = $2; }
;
Index: imcc/t/syn/tail.t
===================================================================
RCS file: /cvs/public/parrot/imcc/t/syn/tail.t,v
retrieving revision 1.2
diff -u -r1.2 tail.t
--- imcc/t/syn/tail.t 4 Mar 2005 17:49:04 -0000 1.2
+++ imcc/t/syn/tail.t 21 Mar 2005 02:20:35 -0000
@@no-spam -3,7 +3,7 @@no-spam
# $Id: tail.t,v 1.2 2005/03/04 17:49:04 bernhard Exp $
use strict;
-use Parrot::Test tests => 3;
+use Parrot::Test tests => 4;
##############################
# Parrot Calling Conventions: Tail call optimization.
@@no-spam -271,3 +271,67 @@no-spam
[doing _funcall]
_fib_step returned 3 values, 23, 20, and 3.
OUT
+
+pir_output_is(<<'CODE', <<'OUT', ".flatten_arg in return");
+
+.sub _main @no-spam
+
+ $P1 = new PerlInt
+ $P1 = 20
+ $P2 = new PerlInt
+ $P2 = 3
+ newsub $P98, .Sub, _fib_step
+ ($P3, $P4, $P5) = _funcall($P98, $P1, $P2)
+ print "_fib_step returned "
+ print argcP
+ print " values, "
+ print $P3
+ print ", "
+ print $P4
+ print ", and "
+ print $P5
+ print ".\n"
+.end
+
+.sub _funcall non_prototyped
+ .param pmc function
+ .local pmc argv
+ argv = foldup 1
+
+ $I33 = defined function
+ unless $I33 goto bad_func
+doit:
+ .pcc_begin prototyped
+ .flatten_arg argv
+ .pcc_call function
+ .pcc_end
+ $P35 = foldup
+ $I35 = $P35
+ print "[got "
+ print $I35
+ print " results]\n"
+ .pcc_begin_return
+ .flatten $P35
+ .pcc_end_return
+bad_func:
+ printerr "_funcall: Bad function.\n"
+ die
+.end
+
+## Return the sum and the two arguments as three integers.
+.sub _fib_step
+ .param pmc arg1
+ .param pmc arg2
+
+ $P1 = new PerlInt
+ $P1 = arg1 + arg2
+ .pcc_begin_return
+ .return $P1
+ .return arg1
+ .return arg2
+ .pcc_end_return
+.end
+CODE
+[got 3 results]
+_fib_step returned 3 values, 23, 20, and 3.
+OUT
[plaintext pcc-return-flatten.patch]
Bob Rogers <rogers-perl6@no-spam> wrote:
> The attached patch is supposed to do two things:
> 1. Makes it possible to say ".flatten foo" as part of a
> .pcc_begin_return/.pcc_end_return sequence. Remarkably, this part of
> the patch is only a one-line change; the internals for call & return are
> closer than the syntax.
Yeah. Call and return are using the same argument setup code.
> 2. Makes ".flatten" equivalent to ".flatten_arg" for all other
> purposes, to emphasize the similarity.
> Unfortunately, though this patch works as intended, it also has a
> number of bizarre side-effects. Here's the summary of failing tests:
Strange. I don't get these test failures (and I can't see, why this
patch would generate such errors).
> ... The t/op/string_cs.t and t/op/stringu.t cases, on the other
> hand, say
> error:imcc:syntax error, unexpected LABEL
The sequence ENC:"STRINGC" is longer then a label token, and I get
USTRINGC as expected.
> It's remotely conceivable that there's a bug in bison and/or flex (I'm
> using the SuSE RPM versions bison-1.875-51.4 and flex-2.5.4a-293).
Could be, yes. I've: bison (GNU Bison) 1.75, flex version 2.5.4
Anyway, applied - thanks.
leo
From: Leopold Toetsch <lt@no-spam>
Date: Mon, 21 Mar 2005 10:10:31 +0100
Bob Rogers <rogers-perl6@no-spam> wrote:
> . . .
> Unfortunately, though this patch works as intended, it also has a
> number of bizarre side-effects . . .
> It's remotely conceivable that there's a bug in bison and/or flex (I'm
> using the SuSE RPM versions bison-1.875-51.4 and flex-2.5.4a-293).
Could be, yes. I've: bison (GNU Bison) 1.75, flex version 2.5.4
Anyway, applied - thanks.
leo
Great; thanks. Not surprisingly, it now works for me on SuSE 9.1 after
doing "cvs update", using the versions of imcc/imcparser.h,
imcc/imclexer.c, and imcc/imcparser.c you put into CVS.
So then I tried rebuilding these files on a SuSE 9.0 machine with
flex-2.5.4a-195 and bison-1.75-109, and found that it fails the exact
same way. That certainly makes it look like SuSE broke something prior
to 9.0.
If someone would like to try to unravel what is going on for the sake
of submitting a bug report, I'd be happy to supply the broken versions
of these files off-list. As for myself, I have lost my appetite for the
chase. At least now I know that I'm not going nuts (at least not in
that particular way), which is a relief. And I've also learned that
I'll need to install flex and/or bison from tarball if I want to use
these machines to hack on IMCC syntax in the future . . .
-- Bob Rogers
http://rgrjr.dyndns.org/