Missing branch instructions?
Pete Lomax
some of my pasm is getting rejected, and I've noticed a couple of
points:
There is an eq_p_i_ic and an eq_p_ic_ic, but not an eq_i_p_ic or an
eq_ic_p_ic. So, I swapped the operands and it worked, but of course
not on an lt statement, so I switched the operands and inverted the
sense, only to find there are no such equivalents for ne, gt, and ge.
There are also eq_ic_ic_ic, eq_nc_nc_ic, eq_sc_sc_ic instructions and
similar for ne, lt, le, gt, and ge. Surely those should automatically
be replaced with branch or no_op/omitted, so what are they for?
Pete
Leopold Toetsch
> There is an eq_p_i_ic and an eq_p_ic_ic, but not an eq_i_p_ic or an
> eq_ic_p_ic. So, I swapped the operands and it worked, but of course
> not on an lt statement, so I switched the operands and inverted the
> sense, only to find there are no such equivalents for ne, gt, and ge.
Yep, you are right, these are missing. I'll add it.
> There are also eq_ic_ic_ic, eq_nc_nc_ic, eq_sc_sc_ic instructions and
> similar for ne, lt, le, gt, and ge. Surely those should automatically
> be replaced with branch or no_op/omitted, so what are they for?
The optimizer handles these (not default for now). They are just
products of the automatic argument permutation.
> Pete
leo
Leopold Toetsch
> ... only to find there are no such equivalents for ne, gt, and ge.
I've added these missing ops now. *But* there are a lot more missing:
* all <op>_p_nc?_ic # <op> := eq, ne, lt, le, gt, ge
* all <op>_p_sc?_ic
* cmp_i_p_nc?
* cmp_i_p_sc?
And we don't support Perl's '==' vs 'eq' opcodes. All current ops try to
do the right thing, but this is mainly a numeric comparison, except for
the obvious <op>_sc?_sc?_ic case.
So we probably need more:
* <op>_str_p_*
* cmp_str_i_p_*
* <op>_int_p_*
* cmp_int_p_*
A Perl compiler will probably emit only the <op>_str or <op>_int
variants. The opcode replacement inside imcc can emit an error or
warning, if the opcodes have the wrong operands, and can replace the
opcodes with the plain variants without _str or _int suffix, if there is
no matching opcode.
Comments welcome
leo
Dan Sugalski
>Pete Lomax <pete...@blueyonder.co.uk> wrote:
>> ... only to find there are no such equivalents for ne, gt, and ge.
>
>I've added these missing ops now. *But* there are a lot more missing:
Yeah, we need all the comparison operators for PMCs in both numeric
and string versions. I'd like to throw a _str and _num suffix on
them, so we have:
eq_str
lt_num
cmp_str
and so on. I think, at this point, that I'm OK with restricting the
eq/lt/whatever unqualified versions to same-type comparisons--i.e.:
eq I5, 13
lt S5, "Foo"
and have them do the obvious thing (numeric or string comparison).
Cross-type comparisons without PMCs won't be allowed, so if you want
this:
lt S5, 12
you'll need to either get the integer contents of S5 or turn 12 into
a string, so it's a two-op sequence. Not too onerous. (int/float
mixes are still OK, they're obvious)
Unqualified eq/cmp/lt are OK for two PMC operations, and call the
underlying unqualified comparison check, but I'd bet that's rarely
used.
>A Perl compiler will probably emit only the <op>_str or <op>_int
>variants. The opcode replacement inside imcc can emit an error or
>warning, if the opcodes have the wrong operands, and can replace the
>opcodes with the plain variants without _str or _int suffix, if there is
>no matching opcode.
Odds are most compilers will go for the explicit string or numeric
comparisons, or MMD on type to figure out which to use, but we can
leave that to the compiler writers. (Enough people have been burned
with the whole "my numbers sorted weird" issue to explicitly specify
numeric or string comparisons pretty much everywhere)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Pete Lomax
>At 12:15 PM +0100 12/7/03, Leopold Toetsch wrote:
>>Pete Lomax <pete...@blueyonder.co.uk> wrote:
>>> ... only to find there are no such equivalents for ne, gt, and ge.
>>
>>I've added these missing ops now. *But* there are a lot more missing:
>
>Yeah, we need all the comparison operators for PMCs in both numeric
>and string versions.
This needs quite careful thought.
>I'd like to throw a _str and _num suffix on
>them, so we have:
>
> eq_str
> lt_num
> cmp_str
I disagree/don't see the point, pls read on.
>
>and so on. I think, at this point, that I'm OK with restricting the
>eq/lt/whatever unqualified versions to same-type comparisons--i.e.:
>
> eq I5, 13
> lt S5, "Foo"
>
>and have them do the obvious thing (numeric or string comparison).
AFIAK, this happens quite reasonably now.
>Cross-type comparisons without PMCs won't be allowed,
Agreed, that's been my (short-term) experience.
>so if you want this:
>
> lt S5, 12
>
>you'll need to either get the integer contents of S5 or turn 12 into
>a string, so it's a two-op sequence. Not too onerous. (int/float
>mixes are still OK, they're obvious)
Yes, 1) get length of string,
2) compare integers.
(or whatever)
>
>Unqualified eq/cmp/lt are OK for two PMC operations,
I'm not convinced at all here. PMC comparison ops, afaict, are based
solely on the pmc instance/address
Here's a snippet to play with:
$P1 = new Array
$P1 = 2
$P1[0] = 1
$P1[1] = 1
$P2 = new Array
$P2 = 2
$P2[0] = 1
$P2[1] = 1
# eq $P1, $P2, _L3
eq "fred", "fred", _L3
print "error \"fred\"!=\"fred\""
_L3:
Is $P1=$P2?
> and call the
>underlying unqualified comparison check, but I'd bet that's rarely
>used.
Well, that's what I'm doing: eq_i_i_*, eq_n_n_*, and eq_s_s_*, I'm
using directly; the rest are going though a check/cast types routine.
Luke Palmer
> I'm not convinced at all here. PMC comparison ops, afaict, are based
> solely on the pmc instance/address
>
> Here's a snippet to play with:
>
> $P1 = new Array
> $P1 = 2
> $P1[0] = 1
> $P1[1] = 1
> $P2 = new Array
> $P2 = 2
> $P2[0] = 1
> $P2[1] = 1
> # eq $P1, $P2, _L3
> eq "fred", "fred", _L3
> print "error \"fred\"!=\"fred\""
> _L3:
>
>
> Is $P1=$P2?
Nope. Mostly because classes/array.pmc says:
/* == operation */
INTVAL is_equal (PMC* value) {
/* XXX */
return 0;
}
:-)
Luke
Dan Sugalski
>On Mon, 8 Dec 2003 11:35:59 -0500, Dan Sugalski <d...@sidhe.org> wrote:
>
>>
>>Unqualified eq/cmp/lt are OK for two PMC operations,
>I'm not convinced at all here. PMC comparison ops, afaict, are based
>solely on the pmc instance/address
Well... no.
>Here's a snippet to play with:
>
> $P1 = new Array
> $P1 = 2
> $P1[0] = 1
> $P1[1] = 1
> $P2 = new Array
> $P2 = 2
> $P2[0] = 1
> $P2[1] = 1
># eq $P1, $P2, _L3
> eq "fred", "fred", _L3
> print "error \"fred\"!=\"fred\""
>_L3:
>
>
>Is $P1=$P2?
Well... maybe. And maybe not. Heck, even this:
new P1, .Foo
set P2, P1
eq P1, P2, OK
may not branch to OK. (There's no requirement that high-level
comparisons require a PMC to be equal to itself)
That's why eq, eq_num, and eq_str for PMC comparisons should call the
three versions of equality vtable functions, and the comparison ops
should do the same depending on whether they're doing a numeric,
string, or generic comparison.
It's important not to confuse these high-level comparisons with
lower-level things like PMC address comparisons.
Melvin Smith
>may not branch to OK. (There's no requirement that high-level
comparisons >require a PMC to be equal to itself)
Although committing such a confusing PMC to Parrot is certainly questionable.
-Melvin
Dan Sugalski
I'm not arguing that one should be part of the base collection, by
any means. However, consider the SQL NULL, or a numeric Infinity.
NULL != NULL, and last I knew (and I may be horribly wrong here :)
Inf != Inf.
Leopold Toetsch
> Yeah, we need all the comparison operators for PMCs in both numeric
> and string versions. I'd like to throw a _str and _num suffix on
> them, so we have:
> eq_str
> lt_num
> cmp_str
Done. Tests wanted :)
leo