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