Opcodes question

[Curtis Rawls]

From working with the optimizer, I have some questions about the PASM
opcodes, in particular the "inout" opcodes. For example, adding
integer registers is defined by the "add(out INT, in INT, in INT)".
But if one of the input registers is also the output register, it can
be simplified to "add(inout INT, in INT)". And additionally, if the
other integer is a constant of value 1, it can be further reduced to
"inc(inout INT)". My question is: Is there an advantage in having
these additional opcodes?

These extra opcodes (besides being less RISCy) are harder to optimize.
Instead of three integer add functions, there are five (from
include/parrot/oplib/ops.h):
PARROT_OP_add_i_i, /* 38 */
PARROT_OP_add_i_i_i, /* 39 */
PARROT_OP_add_i_i_ic, /* 40 */
PARROT_OP_add_i_ic, /* 41 */
PARROT_OP_add_i_ic_i, /* 42 */

This makes it hard to, for example, do constant propagation. If I
have the code:
set I0, 42
add I1, I0, 1
it is simple to propagate the constant 42 to eliminate the first
function and do constant folding on the second. But if I have:
set I0, 42
add I0, 1
the propagation function will have to be smarter than it should have
to be to correctly optimize this code.

So, I would like to know if the runtime handles these "inout"
shorthand opcodes differently than the regular codes. If not, I would
encourage the team to removed them. Also, I suggest that all opcodes
coming into the optimizer should be of the highest possible form, ie
"inc I0" should be "add I0, I0, 1". Conversion to more optimized
opcodes is a type of peephole optimization that should be done at the
very end of the optimization phase.

Just my thoughts,
-Curtis

[Leopold Toetsch]

On Jul 20, 2005, at 9:01, Curtis Rawls wrote:

>
>> From working with the optimizer, I have some questions about the PASM
> opcodes, in particular the "inout" opcodes. For example, adding
> integer registers is defined by the "add(out INT, in INT, in INT)".
> But if one of the input registers is also the output register, it can
> be simplified to "add(inout INT, in INT)". And additionally, if the
> other integer is a constant of value 1, it can be further reduced to
> "inc(inout INT)". My question is: Is there an advantage in having
> these additional opcodes?

Shorter byecode size, a possibly faster representation in the JT
runcore.

> This makes it hard to, for example, do constant propagation. ...

> So, I would like to know if the runtime handles these "inout"
> shorthand opcodes differently than the regular codes. If not, I would
> encourage the team to removed them.

Removing these opcodes isn't and option, now. But ...

> ... Also, I suggest that all opcodes

> coming into the optimizer should be of the highest possible form, ie
> "inc I0" should be "add I0, I0, 1".

... as these optimizations are typically most effective with code
generated by compilers, it's probably simplest to add a paragraph to
docs/compiler_faq.pod, which opcodes should be generated.

> Conversion to more optimized
> opcodes is a type of peephole optimization that should be done at the
> very end of the optimization phase.

Yep.

> Just my thoughts,
> -Curtis

leo