ops and inout PMC - again

[Leopold Toetsch]

My last attempt WRT this got warnocked, so I'll repeat and summarize 
again the issue.

The PARROT_ARGDIR_{IN,OUT,INOUT} defines the directions of information 
flow in and out of Parrot opcodes, for some definition of information.

You could also think of these as LHS-usage (OUT) and RHS-usage (IN). 
This is simple for Ints, Nums, and Strings (where the latter behave like 
values).

PMCs are different. Currently many opcodes with PMCs are defined like:

  B<add>(inout PMC, in PMC)

This is plain wrong. If the LHS PMC doesn't exist yet, you can't call 
its add vtable method (The implementations is $1->vtable->add(...)).

So the PMC is not created, nor is the contents of the P-register 
changed, where this PMC is living in. The ARGDIR just should be "in".

(The current "inout" was a compromise of a similar discussion, we had 
last year)

Another one:

  B<set>(inout PMC, in PMC, in INTKEY)

This is a keyed get operation Px = Py[key]. The result of the operation 
is the contents of the aggregate at the given key. This PMC was somewhen 
created earlier. Now the destination PMC register is set to this 
variable, it has a reference to this now - and the old contents of the 
PMC register is globbered. The ARGDIR of keyed get operations therfore 
has to be "out".

The only users of this ARGDIR thingy are JIT and IMCC. The former does 
currently not deal with PMC registers - though it might sometimes. The 
latter currently has ugly workarounds to get around this
(s. imcc.y /ARGDIR_INOUT)

If sombody has really good reasons to keep the current "inout", then 
please tell us. Otherwise I'll change these "inout" directions - finally.

leo