Nicholas Clark <[EMAIL PROTECTED]> 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 assem
On Thu, Mar 31, 2005 at 06:13:57PM +0200, Leopold Toetsch wrote:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
> > 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:
> >
Luke Palmer <[EMAIL PROTECTED]> wrote:
> 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 <
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
Below inline/attached is a proposal to fix the MMD infix ops.
1) Again the infix ops - yes
>From a HLL point of view:
add d, l, r # PASM op
d = l + r # PIR syntax
d = l."__add"(r) # method call
d = "__add"(l, r) # P
