"potentially ambiguous token after parameter" error [MC68000]

[ProxyPlayerHD]

while working on my 68k CPU file, which is getting more and more stressful, i came across this:

error: potentially ambiguous token after parameter; try using a separating `,`
 144 |
 145 |   ;  Dn <- Dn + (D16/32)
 146 |   ADD.B {dest:D_REGS}, {src}.W                      -> 0b1101[3:0] @ {dest}[2:0] @ 0b000[2:0] @ 0b111[2:0] @ 0b000[2:0] @ {src}[15:0]
     |                             ^                                                                                    

this is a problem because that is just how the 68k works. 0x00000000.W is interpreted as a word (16 bit), and 0x00000000.L is interpreted as a long (32 bit)

here the snippet from the CPU file:

;   Dn <- Dn + (D16/32)
    ADD.B {dest:D_REGS}, {src}.W            -> 0b1101[3:0] @ {dest}[2:0] @ 0b000[2:0] @ 0b111[2:0] @ 0b000[2:0] @ {src}[15:0]
    ADD.W {dest:D_REGS}, {src}.W            -> 0b1101[3:0] @ {dest}[2:0] @ 0b001[2:0] @ 0b111[2:0] @ 0b000[2:0] @ {src}[15:0]
    ADD.L {dest:D_REGS}, {src}.W            -> 0b1101[3:0] @ {dest}[2:0] @ 0b010[2:0] @ 0b111[2:0] @ 0b000[2:0] @ {src}[15:0]
    ADD.B {dest:D_REGS}, {src}.L            -> 0b1101[3:0] @ {dest}[2:0] @ 0b000[2:0] @ 0b111[2:0] @ 0b001[2:0] @ {src}[31:0]
    ADD.W {dest:D_REGS}, {src}.L            -> 0b1101[3:0] @ {dest}[2:0] @ 0b001[2:0] @ 0b111[2:0] @ 0b001[2:0] @ {src}[31:0]
    ADD.L {dest:D_REGS}, {src}.L            -> 0b1101[3:0] @ {dest}[2:0] @ 0b010[2:0] @ 0b111[2:0] @ 0b001[2:0] @ {src}[31:0]

    ADD.B {dest:D_REGS}, {src:s16}          -> 0b1101[3:0] @ {dest}[2:0] @ 0b000[2:0] @ 0b111[2:0] @ 0b000[2:0] @ {src}[15:0]
    ADD.W {dest:D_REGS}, {src:s16}          -> 0b1101[3:0] @ {dest}[2:0] @ 0b001[2:0] @ 0b111[2:0] @ 0b000[2:0] @ {src}[15:0]
    ADD.L {dest:D_REGS}, {src:s16}          -> 0b1101[3:0] @ {dest}[2:0] @ 0b010[2:0] @ 0b111[2:0] @ 0b000[2:0] @ {src}[15:0]
    ADD.B {dest:D_REGS}, {src:i32}          -> 0b1101[3:0] @ {dest}[2:0] @ 0b000[2:0] @ 0b111[2:0] @ 0b001[2:0] @ {src}[31:0]
    ADD.W {dest:D_REGS}, {src:i32}          -> 0b1101[3:0] @ {dest}[2:0] @ 0b001[2:0] @ 0b111[2:0] @ 0b001[2:0] @ {src}[31:0]
    ADD.L {dest:D_REGS}, {src:i32}          -> 0b1101[3:0] @ {dest}[2:0] @ 0b010[2:0] @ 0b111[2:0] @ 0b001[2:0] @ {src}[31:0]

the top 6 instructions are the same as the bottom 6, except that the size of the address is forced by the programmer (either .W(ord) or .L(ong)) the bottom 6 automatically use the best address size, if the address fits inside a 16 bit signed integer it uses the .W(ord) addressing mode, if it doesn't fit it uses the .L(ong) addressing mode. (atleast i hope instruction pritory works from top to bottom and that i'm using the s16 and i32 things correctly)

currently my only real way around this is to comment out the forced address sizes and only have the automatically deciding ones. technically the forced ones aren't even nessesary so i don't know if this is worth "fixing".

[moonheart08]

@ProxyPlayerHD There seems to be an absence of work on this repo now. The best thing that could be done is to try and work on CustomASM yourself.

[hlorenzi]

Ah, sorry for any delay. I think I can relax the requirement for unambiguous tokens after parameters. I'll see what I can do.

On another note, you don't need to use a slice after a binary literal. So for 0b001[2:0], you can just use 0b001 and the assembler will infer you want to use 3 bits (the zeroes are important!). Same for hex literals. Also, if you specify the type of an argument (like s16), you can also omit the slice, and the assembler will assume you want to use the same number of bits as specified in the type.

[ProxyPlayerHD]

Ah, sorry for any delay. I think I can relax the requirement for unambiguous tokens after parameters. I'll see what I can do.

thanks!

On another note, you don't need to use a slice after a binary literal. So for 0b001[2:0], you can just use 0b001 and the assembler will infer you want to use 3 bits (the zeroes are important!). Same for hex literals. Also, if you specify the type of an argument (like s16), you can also omit the slice, and the assembler will assume you want to use the same number of bits as specified in the type.

well i'll probably change that after i'm done and it's working. currently i just want to get done.