Just 256? Why don't you add another argument to the infix opcode?
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 :)
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?
> 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