[PIR] Assignment syntactic sugar restricted to destination parameters

[allison]

IMCC currently allows the '=' syntactic sugar on all opcodes, even when the first register is an input argument rather than an output argument. PIRC correctly detects and handles these cases, so when the transition to PIRC is made any code using, for example:

$S0 = print $P0 = substr 1, 2, "x"

Will have to change to:

print $S0 substr $P0, 1, 2, "x"

This behavior will not be changed in IMCC. See  http://rt.perl.org/rt3/Public/Bug/Display.html?id=36283 for the history.

[kjs]

per above, "will not be changed". closing ticket as "wontfix".

[coke]

On Sat, Oct 24, 2009 at 10:53 AM, Parrot
<parrot-tickets@lists.parrot.org> wrote:
> #906: [PIR] Assignment syntactic sugar restricted to destination parameters
> ---------------------+------------------------------------------------------
>  Reporter:  allison  |        Owner:  kjs
>     Type:  todo     |       Status:  closed
>  Priority:  normal   |    Milestone:  2.6
> Component:  pirc     |      Version:  1.4.0
>  Severity:  medium   |   Resolution:  wontfix
>  Keywords:           |         Lang:
>    Patch:           |     Platform:
> ---------------------+------------------------------------------------------
> Changes (by kjs):
>
>  * status:  new => closed
>  * resolution:  => wontfix
>
>
> Comment:
>
>  per above, "will not be changed". closing ticket as "wontfix".
>
> --
> Ticket URL: <https://trac.parrot.org/parrot/ticket/906#comment:1>
> Parrot <https://trac.parrot.org/parrot/>
> Parrot Development
> _______________________________________________
> parrot-tickets mailing list
> parrot-tickets@lists.parrot.org
> http://lists.parrot.org/mailman/listinfo/parrot-tickets
>

But this still needs to be addressed in PIR eventually - the thought
being that this syntax restriction will exist in PIRC. This ticket
needs to stay open.

-- 
Will "Coke" Coleda

[plobsing]

Replying to coke:

This was an easy fix. In the attached patch I have made it a warning (as opposed to a flat out error).

However, it causes a number of our tests to fail. Anyone wanting this feature badly enough can commit the patch after fixing the induced errors.

[plobsing]

patch to IMCC to catch assignment syntax for input and inout registers

[coke]

This points to a some cases where we have ops defined as, e.g.:

inline op mul(invar PMC, invar PMC, invar PMC) :base_core {
    $1 = VTABLE_multiply(interp, $2, $3, $1);
}

is invar the right declaration for $1 there?

[coke]

We could also use some test cases (TODO'd for now) for this that verify that the assignment works and/or is prohibited for a few opcodes.

[plobsing]

Replying to coke:

This points to a some cases where we have ops defined as, e.g.:

inline op mul(invar PMC, invar PMC, invar PMC) :base_core {
    $1 = VTABLE_multiply(interp, $2, $3, $1);
}

is invar the right declaration for $1 there?

It would be more correct to have that as inout (such errors would seriously throw off any attempt at register allocation for example).

However, it still would not allow "$P0 = mul $P1, $P2" syntax, because the op continues to use the LHS register as an input.

A workaround is that sugared unary and binary ops circumvent the check; "$P0 = $P1 * $P2" (which gets translated to "mul $P0, $P1, $P2"), "$P0 = 5" (set $P0, 5), etc... do not trigger the assignment warning despite treating the LHS as an input.

[plobsing]

1) The assign syntax sugar is a horrible hack and makes implications about semantics that simply aren't true (bind vs assign). It was a mistake.

2) Issues with inout vars on certain ops expected to be "mostly assignish" prevent this working with perfectly sane PIR (for as sane as PIR can be).

3) We've had a patch to accomplish this with IMCC for 6 months but due to issues mentioned above, this has not been done.