[CVS ci] opcode cleanup 1 - minus 177 opcodes
Leopold Toetsch
* other VMs might already have a negative opcode count w this change ;)
* there are 3 incompatible changes: see ABI_CHANGES
* all other removed opcodes get replaced with equivalent ops
* opcodes got renumbered and shuffled - please recompile your PBCs [1]
* ops/ops.num is now the ultimate source of valid opcodes, except for
opcodes in ops/experimental.ops, which are included in core_ops*.c
nethertheless
[1] I'll remove some more ops RSN so you might wait to use this version
in production.
Opcodes to be removed:
1) Almost half of the non-PMC compare and branch opcodes according to:
lt a, b, L1 => ge b, a, L1
2) Very likley (unless one loudly hollers): all opcodes with FLOATVAL
constants except set_x_nc and assign_x_nc . These are 107 opcodes with
no counterpart in JIT or hardware. The constants have to be loaded from
the constant table anyway, so we might that just do it in a separate opcode.
leo
Nicholas Clark
> 1) Almost half of the non-PMC compare and branch opcodes according to:
>
> lt a, b, L1 => ge b, a, L1
I read this and thought of a subtle problem. So I tried some code, and I
surprised myself. I don't think that your logic is correct:
$ /usr/bin/perl -le 'print "$a < $b: ", $a < $b, "\n$b >= $a: ", $b >= $a while ($a, $b) = splice @ARGV, 0, 2' 1 2 1 1
1 < 2: 1
2 >= 1: 1
1 < 1:
1 >= 1: 1
After experimenting, I think that it should be
lt a, b, L1 => gt b, a, L1
Which works for the subtle problem that I thought of:
$ /usr/bin/perl -le 'print "$a < $b: ", $a < $b, "\n$b > $a: ", $b > $a while ($a, $b) = splice @ARGV, 0, 2' 1 2 1 1 nan 1
1 < 2: 1
2 > 1: 1
1 < 1:
1 > 1:
nan < 1:
1 > nan:
So I was wrong on that one. (NaNs may be crazy, but at least they're still
commutative.)
If I'm right, then this doesn't say good things about the completeness of
our regression tests.
Nicholas Clark
Leopold Toetsch
> On Sat, Nov 27, 2004 at 10:34:17AM +0100, Leopold Toetsch wrote:
>> 1) Almost half of the non-PMC compare and branch opcodes according to:
>>
>> lt a, b, L1 => ge b, a, L1
*g*
> I read this and thought of a subtle problem. So I tried some code, and I
> surprised myself. I don't think that your logic is correct:
Yes. Thanks. I mixed that up with "not (a < b)" which is a bit different.
> After experimenting, I think that it should be
> lt a, b, L1 => gt b, a, L1
Yep. And that's in CVS already, just the other direction.
> If I'm right, then this doesn't say good things about the completeness of
> our regression tests.
A lot of tests were failing, when I had it wrong. That's fine.
> Nicholas Clark
leo
Dan Sugalski
>See also subject "Too many opcodes".
>
>* other VMs might already have a negative opcode count w this change ;)
>* there are 3 incompatible changes: see ABI_CHANGES
>* all other removed opcodes get replaced with equivalent ops
>* opcodes got renumbered and shuffled - please recompile your PBCs [1]
>* ops/ops.num is now the ultimate source of valid opcodes, except for
> opcodes in ops/experimental.ops, which are included in core_ops*.c
> nethertheless
Could you undo this please? Now is not the time to be trimming ops
out. We can do that later, closer to release, if we choose to do it
at all.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Thomas Seiler
> At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
>
>> See also subject "Too many opcodes".
>>
>>
> Could you undo this please? Now is not the time to be trimming ops out.
OTOH, it won't hurt anyone and it is already in.
So why bother, unless of course there is a technical reason...
In any case, there is some stuff worth keeping, IMHO:
* (is)?l[t,e]_i_i_i and (is)?g[t,e]_i_i_i *are* redundant
* rand* should not be ops
* lcm_n_i_i doesnt make any sense as the result is an integer
* constant folding (no need for opvariants with two constant args)
now is as good as ever for those
Then there are changes that need more thought:
* replacing *_i_n with *_n_n uses a N-register and might
put stress on the register allocator in case of heavy "floating" code.
Doing these now smells in fact a bit like premature optimisation...
So I would like to propose salami-tactic and try to find the offending
slices (the ones with the pepper) instead of rejecting the whole salami.
just my 2 cents though
tom
Leopold Toetsch
> Dan Sugalski wrote:
>> At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
>>
>>> See also subject "Too many opcodes".
>>>
> >> [...]
> >>
>> Could you undo this please? Now is not the time to be trimming ops out.
When is the time? After another 1000 opcodes are in, which all ought to
be functions?
> OTOH, it won't hurt anyone and it is already in.
That's my point. Minus 226 opcodes and all works (modulo the 3
documented incompatible changes like the lcm cruft)
> So why bother, unless of course there is a technical reason...
> In any case, there is some stuff worth keeping, IMHO:
> * (is)?l[t,e]_i_i_i and (is)?g[t,e]_i_i_i *are* redundant
> * rand* should not be ops
> * lcm_n_i_i doesnt make any sense as the result is an integer
> * constant folding (no need for opvariants with two constant args)
> now is as good as ever for those
Yep, thanks for the summary.
> Then there are changes that need more thought:
> * replacing *_i_n with *_n_n uses a N-register and might
> put stress on the register allocator in case of heavy "floating" code.
> Doing these now smells in fact a bit like premature optimisation...
No, because it introduces exactly one reusable temporary. The mixed _n_i
variants were almost all not supported by the JIT core. A mapped INT
register had first to store the INT back into the Parrot register before
the float can be used.
> So I would like to propose salami-tactic and try to find the offending
> slices (the ones with the pepper) instead of rejecting the whole salami.
> just my 2 cents though
> tom
leo
Thomas Seiler
> Thomas Seiler <t.se...@epfl.ch> wrote:
>
>>Dan Sugalski wrote:
>>
>>>At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
>>>
>>>
>>>>See also subject "Too many opcodes".
[...]
>>Then there are changes that need more thought:
>>* replacing *_i_n with *_n_n uses a N-register and might
>>put stress on the register allocator in case of heavy "floating" code.
>>Doing these now smells in fact a bit like premature optimisation...
> No, because it introduces exactly one reusable temporary. The mixed _n_i
> variants were almost all not supported by the JIT core. A mapped INT
> register had first to store the INT back into the Parrot register before
> the float can be used.
You are right about execution time of the two ops compared to the old
op, but I think the one reusable temporary can cause N-register
spilling, an that can hurt performance. On the other hand, those ops
might not be *that* frequent.
This will need some real life (PDL?) code to benchmark with, IMHO.
Another change that need more thought:
* (is)?g[t,e] N, P variants are *not* redundant
think of NaN's, custom vtables,... order is important there,
I have a feeling like replacing gt with lt might influence the
program flow in some egde cases.
tom
Leopold Toetsch
> Another change that need more thought:
> * (is)?g[t,e] N, P variants are *not* redundant
Ops with PMCs aren't changed at all.
,--[ ABI_CHANGES ]-------------------------------------------------
| The compare and branch opcodes gt, ge, isgt, and isge for I, N, S
| arguments are not emitted any more.
`------------------------------------------------------------------
leo
Dan Sugalski
>Thomas Seiler <t.se...@epfl.ch> wrote:
>> Dan Sugalski wrote:
>>> At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
>>>
>>>> See also subject "Too many opcodes".
>>>>
>> >> [...]
>> >>
>>> Could you undo this please? Now is not the time to be trimming ops out.
>
>When is the time? After another 1000 opcodes are in, which all ought to
>be functions?
Yes. Y'know, when we start doing the optimization based on a fully
designed and implemented engine. Anything before that's premature.
(Shall I go dig up a half dozen or more archive references with you
chiding me for premature optimizations?)
> > OTOH, it won't hurt anyone and it is already in.
>
>That's my point.
Then your point's wrong. This patch broke a lot of my code.
You keep wanting to chop things out of the core. Stop. That's not
your call -- it's mine, and it will be made, but not now.
Put these back.
Michael Walter
position to judge whether it is appropriate in this case, though.
Back-to-reading-mode-ly yours,
Michael
On Mon, 29 Nov 2004 20:25:48 -0500, Dan Sugalski <d...@sidhe.org> wrote:
> At 8:29 AM +0100 11/28/04, Leopold Toetsch wrote:
> >Thomas Seiler <t.se...@epfl.ch> wrote:
> >> Dan Sugalski wrote:
> >>> At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
> >>>
> >>>> See also subject "Too many opcodes".
> >>>>
> >> >> [...]
> >> >>
> >>> Could you undo this please? Now is not the time to be trimming ops out.
> >
> >When is the time? After another 1000 opcodes are in, which all ought to
> >be functions?
>
> Yes. Y'know, when we start doing the optimization based on a fully
> designed and implemented engine. Anything before that's premature.
> (Shall I go dig up a half dozen or more archive references with you
> chiding me for premature optimizations?)
>
> > > OTOH, it won't hurt anyone and it is already in.
> >
> >That's my point.
>
Dan Sugalski
>There is also such thing as premature "pessimization". I'm not in the
>position to judge whether it is appropriate in this case, though.
Oh, absolutely. In this case the issues are personal taste (Leo
doesn't like the big list) and issues with specific inefficiencies in
the way we've got some of the automated infrastructure being built.
While there are pessimal things that need fixing it's important to
look at the things that are broken, not the things that we don't like.
It would've been clearer had I taken things in front-to-back order,
but I didn't -- there's a longish message that came after this one
explaining what needs to be done.
Leopold Toetsch
> ... This patch broke a lot of my code.
All opcode permutations [1] are still valid. Can you please provide a
PASM snippet that doesn't work anymore.
[1] except abs I, N which was the only opcode with an integer result for
a float argument and lcm N,I,I which converted the integer result to
float. All other opcode should work without any change.
leo