"no match found for instruction" when mnemonic is less than 4 characters long (and has a subruledef directly next to it)

[ProxyPlayerHD]

ey, haven't used this program in a while. but i've gotten back into 68k Assembly so i dusted the old files off and started working on it again.

but i noticed that my version of CustomASM was pretty outdated so i updated it, and as expected it broke some stuff. specifically unlike the old version i used the newest one (v0.13.3) was unable to resolve any condional branch instructions. i copied all nesseary parts for the error to appear from the 68k CPU file:

#subruledef CC
{
    CC => 0b0100
    CS => 0b0101
    EQ => 0b0111
    GE => 0b1100
    GT => 0b1110
    HI => 0b0010
    LE => 0b1111
    LS => 0b0011
    LT => 0b1101
    MI => 0b1011
    NE => 0b0110
    PL => 0b1010
    VC => 0b1000
    VS => 0b1001
}

#ruledef
{
    B{con:CC} {DEST}    => {rel = (DEST - (pc + 2)), assert(rel <= 126 && rel >= -128 && rel != 0), 0b0110 @ con`4 @ rel`8}
    B{con:CC} {DEST}    => {rel = (DEST - (pc + 2)), assert(rel <= 32766 && rel >= -32768), 0b0110 @ con`4 @ 0x00 @ rel`16}
}

START:
BNE START

but i was able to further narrow it down to this minimal setup:

#subruledef SELECT
{
    C => 0b1
}

#ruledef
{
    A{sel:SELECT}       => 0b0000000 @ sel`1    ; 1 Character
    AB{sel:SELECT}      => 0b0000001 @ sel`1    ; 2 Characters
    ABB{sel:SELECT}     => 0b0000010 @ sel`1    ; 3 Characters
    ABBB{sel:SELECT}    => 0b0000011 @ sel`1    ; 4 Characters
}

AC  ; Fails
ABC ; Fails
ABBC    ; Fails
ABBBC   ; Works?

this is also where the name for the title comes from, because if you put a whitespace character between the instruction and {sel:SELECT} it works regardless of the amount of characters in the instruction.... but of course that is not really an option as the branches cannot have whitespaces in their mnemonic. so i'm hoping this can be fixed so that instructions of any length can use subruledefs as part of their mnemonic.

[hlorenzi]

Oh, no... I wonder if this has to do with the optimization step used by the matcher. Could you try running with --debug-no-optimize-matcher for the time being, to see if it solves the issue while I work on a fix?

[chrisgbk]

I tried the example with the debug flag, and it made no difference in the behavior.

[peterbudai]

I tried the example with the debug flag, and it made no difference in the behavior.

I can confirm this, I encountered the same issue, and the debug flag did non change the outcome.

[hlorenzi]

Turns out there was an oversight with that debug flag, and it wasn't working at all... 🤦 The non-optimized matcher algorithm did avoid this issue, indeed. It was a problem with the optimized algorithm.