Again the infix ops

[Leopold Toetsch]

Below inline/attached is a proposal to fix the MMD infix ops.

[Luke Palmer]

Leopold Toetsch writes:
> But with one more indirection a PIC-like scheme can work with
> read-only bytecode too (probably). E.g. the assembler emits instead
> of the proposed:
>
> infix "__add", Pd, Pl, Pr
>
> this opcode:
>
> infix (.MMD_ADD << 24) | n, Pd, Pl, Pr

Just 256? Why don't you add another argument to the infix opcode?

Luke

[Leopold Toetsch]

256 diffent infix operations with the signature _p_p_p should doit it
for a while. If not the assembler can emit C<infix2> for the next bunch
of 256 :)

> Luke

leo

[Nicholas Clark]

Can 2 different bytecode segments each try to define a new infix operator?
If so, how do they number their infix operators to avoid a clash?

Nicholas Clark

[Leopold Toetsch]

Nicholas Clark <ni...@ccl4.org> wrote:

> Can 2 different bytecode segments each try to define a new infix operator?
> If so, how do they number their infix operators to avoid a clash?

The same problem arises with user defined opcodes or generally for a
name => index mapping for which the assembler and the Parrot run cores
need the same view.

I see three possible solutions:

1) demand predeclaration of such resources in main (at compile time):

$I0 = register_infix "__hyper_add" # assign next infix op number

or a variation of this theme: demand that the assembler and runtime
"executes" such registration in the same order.

2) do a runtime lookup

infix "__hyper_add", Pd, Pl, Pr

3) treat unknown infix ops as ordinary multi sub calls

Pd = "__hyper_add"(Pl, Pr)

With runcores that can rewrite the bytecode all three boil down to the
same and fast PIC-based operation.

> Nicholas Clark

leo