[perl #36283] pasm/pir: forbid assignment syntax for inout params
# New Ticket Created by Chip Salzenberg # Please include the string: [perl #36283] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36283 > It makes sense to allow e.g. C<$P0 = add $P1, $P2> as alternative syntax for C. However, when the first parameter is "inout" rather than "out", assignment syntax is *not* appropriate. For example, C actually modifies $P0 rather than just assigning to it, so C<$P0 = substr 1, 2, "x"> is just wrong, and should be a compile-time error. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: PDD03: The new boss
Bob Rogers wrote: So, IMHO, it seems more versatile to have these opcodes operate on one arg/return at a time, instead of monolithically on the whole list: set_arg , , If somehow possible, I'd really like to avoid indirect register addressing. The register allocator can't track the involved register because the effect can happen at runtime. See also the C opcode and the comment there. It also leaves room for such things as: flatten_arg , , While it's not coded yet, it could be something like: .get_params "(0x8)", $P5, $P6, $P7 and you'll get the first 3 values from the passed in array. foldup_return , , .set_returns "(0x10,0x10,0x10)", $P5, $P6, $P7 # mark 3 pmcs as being returned as array The array will actually not be created except the caller awaits one. To ignore a parameter, simply don't fetch it. To ignore a return, simply don't supply a register for it. Yep - that's still doable, but not in the middle, which looks insane to me anyway. One still needs something equivalent to argc (but probably only one), in order to find out what needed defaulting. To see if whether or not the Nth argument was supplied [1], just compare N to argc. The proposal has argcI, argcP, ... I would also argue that the generated PIR should be in charge of signalling language-specific "too few/many" args errors. (The language may be required to do so in any case.) I expect that we end up with some context error/warning flags that cover various mismatches of argument passing. Please note: the old conventions didn't really specify what should happen for an args/params mismatch. It was more a "don't do that then or check it yourself". If we wanted to be really radical (is my head still spinning?), we could promote call frames to first-class objects. Let's postpone this a bit. [1] Common Lisp allows a "supplied-p-parameter" variable to be bound for optional and keyword arguments; see http://www.lispworks.com/documentation/HyperSpec/Body/03_da.htm for details. Could you please translate this to PIR or some such ;-) leo
Re: PDD03: The new boss
On Tue, Jun 14, 2005 at 11:48:06AM +0200, Leopold Toetsch wrote: > Bob Rogers wrote: > > So, IMHO, it seems more versatile to have these opcodes operate on > >one arg/return at a time, instead of monolithically on the whole list: > > > > set_arg , , > > If somehow possible, I'd really like to avoid indirect register > addressing. I think Bob's proposal is actually harmless WRT aliasing. It's indirect indexing, but only of the explicitly enumerated _arguments_ or _return_value_ registers that appeared in the source code and are thus visible to the allocator. Which is not to say I think it's a good idea. When performance matters, batching is good and unbatching is bad. And in parameter and return value processing, performance *matters*, a lot. Unbatching would also raise issues WRT the lifetimes of returning functions' register frames ... the number of opcodes that would process the return value would potentially be unbounded, so the returning function's parameters would have to be stored somewhere (expensive) or the dead invocation's register frame would have to be kept around (also expensive). So I think the one-opcode-per-parameter idea is pretty much a non-starter. > > foldup_return , , > > .set_returns "(0x10,0x10,0x10)", $P5, $P6, $P7 > # mark 3 pmcs as being returned as array Unless I've misunderstood its purpose, I don't think that "foldup" is a good feature here. There's no reason a subroutine shouldn't be expected create an Array (or other aggregate of its choice -- note that the specific type may be important) and return it. > The proposal has argcI, argcP, ... "The proposal"? (Register-)color me confused. > I expect that we end up with some context error/warning flags that > cover various mismatches of argument passing. Core language exceptions that the upper language can translate, or perhaps HLL-specific hooks. Or maybe even an additional parameter to the opcode for a label that's taken when something goes wrong...? -- Chip Salzenberg <[EMAIL PROTECTED]>
Pondering the unification of @MULTI and get_params
{Pre-Post-Script: After all this trouble below, which is hairy and yet
not even complete, parameter-by-parameter conversion is actually
starting to look good for complex cases. Despite all my reasons
against it. I start to suspect that we need both; that get_params
can be used for cases that are quite simple, and get_param [one at a
time] can be introduced for more complex cases.}
Currently, @MULTI declares metadata that are attached to the Sub
structure, while get_params claims to be an executable opcode but
that's a deception -- since Parrot is cheating by looking for the
opcode and saving a pointer to it, it's really metadata that just
takes the form of an opcode. Since we're going to need type
validation for all parameters, not just invocant(s), it makes no sense
to embed any type information in an invocant-specific construct like
@MULTI.
So all the information currently in these places, plus more, should be
collected into a single construct that is explicitly metadata. Most
of the difficulty of the Perl6 syntax is related to the complex ways
to specify a type. At the Parrot level, we can assume that complex
types will be constructed with artificial names, so all we have left
to see is the parameter, its type, the register to put it in, and the
flags that we've started defining. The ".param" pseudo-op is headed
in the right direction, for example; we just need more info.
.sub __add
.param MyType $P0 :flags(0x40) # or @flags(0x40)? - inv. w/o colon
(e.g.)
.param $I0 :flags(0x20) # invocant with colon (e.g.)
As for default values: That's tough. Optional P parameters can be
left as null when they're missing. In addition, we'll probably need
to keep a bit mask of parameter-present flags which can be queried.
(Alternatively we could have a word pointing to a label which contains
code that will initialize the given parameter when it's missing. But
that's pretty ugly, and probably doesn't save us much.)
Named parameters will need an extra word for each feature to hold the
string contant containing the string name. Looks like we're even
going to be variable length represenation per-parameter.
What do you think?
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: [perl #34912] Badly balanced at classes/pmc2c2.pl
On Sunday 12 June 2005 16:28, Will Coleda via RT wrote: > Jens - is this still an issue? yes. I've no clue whats wrong. Maybe its a perl 5.6.0 bug. I don't know how to fix it. jens
[PATCH] [perl #36269] Alignment problems with doubles on SPARC.
On Mon, 13 Jun 2005, Andy Dougherty wrote:
> On Mon, 13 Jun 2005, Leopold Toetsch via RT wrote:
>
> > Chip Salzenberg wrote:
> > > On Mon, Jun 13, 2005 at 02:57:09PM -0400, Andy Dougherty wrote:
> >
> > >>Yes. The compiler does the right thing. It sensibly reports
> > >>that sizeof(PMC) = 24 for SPARC.
> > >
> > > Then I remain puzzled how Parrot could ever misalign a double.
> >
> > Yes. So I am. Could somone please run this PASM snippet in a debugger so
> > that we can see, where it fails.
>
> Here's where it fails:
>
> (dbx) run ../num2.pasm
> (process id 7721)
> [EMAIL PROTECTED] ([EMAIL PROTECTED]) signal BUS (invalid address alignment)
> in Parrot_set_n_nc (optimized) at line 149 in file "set.ops"
> 149 goto NEXT();
> (dbx) where
> current thread: [EMAIL PROTECTED]
> =>[1] Parrot_set_n_nc(cur_opcode = ???, interpreter = ???) (optimized), at
> 0xa9160 (line ~149) in "set.ops"
> [2] runops_slow_core(interpreter = ???, pc = ???) (optimized), at 0xdd2a0
> (line ~105) in "runops_cores.c"
> [3] runops_int(interpreter = ???, offset = ???) (optimized), at 0xdbc70 (line
> ~657) in "interpreter.c"
> [4] runops(interpreter = ???, offs = ???) (optimized), at 0xdc6d4 (line ~40)
> in "inter_run.c"
> [5] Parrot_runcode(interpreter = ???, argc = ???, argv = ???) (optimized), at
> 0x8482c (line ~757) in "embed.c"
> [6] Parrot_runcode(interpreter = ???, argc = ???, argv = ???) (optimized), at
> 0x846ac (line ~757) in "embed.c"
> [7] main(argc = ???, argv = ???) (optimized), at 0x68058 (line ~448) in
> "main.c"
>
> Alas, since this is an optimized compile, there is no single stepping in the
> debugger.
The following patch fixes the core dump for me. The problem appears to be
in , where the 'data' segment is declared as a (void *), but is
then assumed to be aligned suitably for holding a double. I fixed that
with a union. The compiler then automatically assures that the elements
are aligned. I still need to go through places where the data element is
assigned to various things through casts and check whether any additional
members to the union ought to be added.
While hunting for a solution, I saw a lot of places in the code that
appear to be worried about alignment. In many cases it was not clear to
me what needs to be aligned with what and why. Is it for alignment of
doubles? Then we should use a double type where appropriate. Is it for
alignment of one structure with another (like perl's sv/av/hv/
structures)? If so, that should be documented carefully somewhere. Is it
for alignment with blocks returned by memalign? I didn't know, so I put
in questions in the comments.
Gcc currently gives the warning:
cast increases required alignment of target type 7,151 times. One of
those was actually the key to solving this problem. Eventually, it'd be
nice to get rid of the other 7150, even if they are all false alarms.
diff -r -u parrot-orig/include/parrot/debug.h parrot-andy/include/parrot/debug.h
--- parrot-orig/include/parrot/debug.h Mon Jun 6 09:07:45 2005
+++ parrot-andy/include/parrot/debug.h Tue Jun 14 14:01:06 2005
@@ -52,8 +52,8 @@
typedef struct PDB_condition {
unsigned short type;
unsigned char reg;
-unsigned char dummy; /* For alignment */
-void*value;
+unsigned char dummy; /* For alignment XXX ?? */
+void*value; /* What neeeds to be aligned with
what? */
PDB_condition_ptr next;
} PDB_condition_t;
diff -r -u parrot-orig/include/parrot/jit.h parrot-andy/include/parrot/jit.h
--- parrot-orig/include/parrot/jit.hMon Jun 6 09:08:05 2005
+++ parrot-andy/include/parrot/jit.hTue Jun 14 14:02:54 2005
@@ -30,8 +30,8 @@
int type;
ptrdiff_t native_offset;
charskip;
-chardummy[3]; /* For alignment */
-union {
+chardummy[3]; /* For alignment ??? XXX */
+union { /* What has to align with what? */
opcode_topcode;
void(*fptr)(void);
} param;
@@ -124,8 +124,8 @@
char isjit;
char done;
char ins_count;
-char dummy; /* For alignment */
-int block;
+char dummy; /* For alignment ??? XXX */
+int block; /* What has to align with
what? */
Parrot_jit_optimizer_section_ptr branch_target;
Parrot_jit_optimizer_section_ptr prev;
Parrot_jit_optimizer_section_ptr next;
@@ -151,8 +151,8 @@
char*map_branch;
opcode_t **branch_list;
unsigned charhas_unpred
[perl #36286] [PATCH] Turn off optimization on another large file.
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #36286]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36286 >
My system couldn't handle an optimized compile of ops/core_ops_switch.c.
Ideally, there should be some easy way to put such things in hints files,
and also some way to override it on a per-file basis after running
Configure, e.g. with something like make OPTIMZE="" . But for now, this
will do for me.
diff -r -u parrot-orig/config/gen/makefiles/CFLAGS.in
parrot-andy/config/gen/makefiles/CFLAGS.in
--- parrot-orig/config/gen/makefiles/CFLAGS.in Mon Jun 6 09:14:19 2005
+++ parrot-andy/config/gen/makefiles/CFLAGS.in Tue Jun 14 10:14:30 2005
@@ -8,6 +8,7 @@
src/spf_render.c -{-Wformat-nonliteral} # noisy
src/tsq.c-{${optimize}} # never optimize tsq.c!
ops/core_ops_cg.c -{${optimize}} # takes too long
+ops/core_ops_switch.c -{${optimize}} # Overwhelms some compilers.
src/py_func.c +{-Iclasses} # include pmc_default.h
# io should be -Wunsed clean
--
Andy Dougherty [EMAIL PROTECTED]
Re: Pondering the unification of @MULTI and get_params
On 6/14/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote: > .sub __add > .param MyType $P0 :flags(0x40) # or @flags(0x40)? - inv. w/o colon > (e.g.) > .param $I0 :flags(0x20) # invocant with colon (e.g.) ... > What do you think? I think the typecodes are unnecessary with a metadata syntax, and the numeric codes in general are looking increasingly silly. If this isn't a normal opcode, why not just detect the register type and use a space-separated list of keywords, and save people the mental bit-twiddling? .param Int $P0 .param Str $P1 .param Array $P2 fold -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Pondering the unification of @MULTI and get_params
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Tue, 14 Jun 2005 11:48:06 +0200
Bob Rogers wrote:
. . .
>To ignore a parameter, simply don't fetch it. To ignore a return,
> simply don't supply a register for it.
Yep - that's still doable, but not in the middle, which looks insane to
me anyway.
Not always, seems to me. Sometimes, in order to implement a defined
protocol (e.g. for a callback), you must accept a parameter that you
don't need. If the compiler can avoid allocating a register for it,
then that is a useful optimization, albeit a small one.
The same argument applies for multiple returns; arguably, this is the
more common case.
But this argument only applies to receiving values; I agree that it's
a bad idea to allow (e.g.) passing the first and third value to a
function, but not the second. I have seen languages that support this
(at least one anyway), but I'm not sure it's worth the bother. IMHO, it
addresses a need that named parameters address better.
>I would also argue that the generated PIR should be in charge of
> signalling language-specific "too few/many" args errors. (The language
> may be required to do so in any case.)
I expect that we end up with some context error/warning flags that cover
various mismatches of argument passing. Please note: the old conventions
didn't really specify what should happen for an args/params mismatch.
It was more a "don't do that then or check it yourself".
Yes, and that has always seemed fine to me. Common Lisp requires the
following [1] in such cases:
If this situation occurs in a safe call, an error of type
PROGRAM-ERROR must be signaled; and in an unsafe call the
situation has undefined consequences.
Either way, the compiler needs to generate the appropriate code; I don't
expect Parrot to do that for me.
>If we wanted to be really radical (is my head still spinning?), we
> could promote call frames to first-class objects.
Let's postpone this a bit.
No prob. ;-}
> [1] Common Lisp allows a "supplied-p-parameter" variable to be bound
> for optional and keyword arguments; see
> http://www.lispworks.com/documentation/HyperSpec/Body/03_da.htm for
> details.
Could you please translate this to PIR or some such ;-)
leo
Actually, I started to extract some examples from compiler output for my
previous post, but I was afraid that would be too noisy. I'll see if I
can produce something intelligible, but under separate cover.
From: Chip Salzenberg <[EMAIL PROTECTED]>
Date: Tue, 14 Jun 2005 12:34:02 +0200
On Tue, Jun 14, 2005 at 11:48:06AM +0200, Leopold Toetsch wrote:
> > foldup_return , ,
>
> .set_returns "(0x10,0x10,0x10)", $P5, $P6, $P7
> # mark 3 pmcs as being returned as array
Unless I've misunderstood its purpose, I don't think that "foldup" is
a good feature here. There's no reason a subroutine shouldn't be
expected create an Array (or other aggregate of its choice -- note that
the specific type may be important) and return it.
The (called) subroutine could do that, but what if the callee is written
to return a series of separate values, but the caller wants them all as
a single object? The Common Lisp multiple-value-list form [3] comes to
mind here; it allows the caller to accept all values without knowing in
advance how many there might be.
> The proposal has argcI, argcP, ...
"The proposal"? (Register-)color me confused.
Me too; I didn't see these . . .
From: Chip Salzenberg <[EMAIL PROTECTED]>
Date: Tue, 14 Jun 2005 14:12:54 +0200
{Pre-Post-Script: After all this trouble below, which is hairy and yet
not even complete, parameter-by-parameter conversion is actually
starting to look good for complex cases. Despite all my reasons
against it. I start to suspect that we need both; that get_params
can be used for cases that are quite simple, and get_param [one at a
time] can be introduced for more complex cases.}
Now that you mention it, I can see that having both would be beneficial
even for the complex cases, if the boundary can be drawn appropriately.
It would be ideal if get_params (or Sub metadata) could do most of the
work, with additional ops to support the hairier stuff when needed.
Unfortunately (or perhaps fortunately), I'm out of time for making more
detailed suggestions.
Currently, @MULTI declares metadata that are attached to the Sub
structure, while get_params claims to be an executable opcode but
that's a deception . . .
So all the information currently in these places, plus more, should be
collected into a single construct that is explicitly metadata . . .
I think this is a great idea. Such metadata would of course be useful
to a debugger as well. The potential problem with metadata, though, is
that it may be overly prescriptive; if the metadata can't describe
something, it
