Ticket #906 (closed deprecation: wontfix)

Opened 5 years ago

Last modified 4 years ago

[PIR] Assignment syntactic sugar restricted to destination parameters

Reported by: allison Owned by: kjs
Priority: normal Milestone: 2.6
Component: pirc Version: 1.4.0
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description

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.

Attachments

pir_assign.patch Download (0.7 KB) - added by plobsing 4 years ago.
patch to IMCC to catch assignment syntax for input and inout registers

Change History

  Changed 5 years ago by kjs

  • status changed from new to closed
  • resolution set to wontfix

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

  Changed 5 years ago by coke

  • status changed from closed to reopened
  • resolution wontfix deleted
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

follow-up: ↓ 4   Changed 4 years ago by coke

  • type changed from todo to deprecated

in reply to: ↑ 3   Changed 4 years ago by 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.

Changed 4 years ago by plobsing

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

follow-up: ↓ 7   Changed 4 years ago by 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?

  Changed 4 years ago by 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.

in reply to: ↑ 5   Changed 4 years ago by 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.

  Changed 4 years ago by plobsing

  • status changed from reopened to closed
  • resolution set to wontfix

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.

Note: See TracTickets for help on using tickets.