Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional instruction arguments -> no match #216

Closed
jmerdich opened this issue Jan 30, 2025 · 2 comments
Closed

Optional instruction arguments -> no match #216

jmerdich opened this issue Jan 30, 2025 · 2 comments
Labels

Comments

@jmerdich
Copy link

About half the instructions in the DSP56k can take an optional 'parallel move' directive which is otherwise just padding. Since this applies to so many instructions, I'd like to use a subrule that can evaluate to nothing, but it doesn't seem like the existing 'optional' matcher can match in that case. I'm open to expressing this some other way if this isn't idiomatic.

#subruledef acc {
    a => 0`1
    b => 1`1
}
#subruledef paropts {
    {} => 0`16  ; Optional and not provided, all fields are 0.
    FOO => 1`16 ; Demonstrate having an arg works, not actual syntax
}
#ruledef {
    nop =>  0`24
    abs {reg: acc} {p : paropts} => 2`4 @ reg @ 6`3 @ p
}
nop
abs a FOO
abs a

Provides:

customasm v0.13.7 (x86_64-pc-windows-msvc)
assembling `.\dsp56.asm`...
error: no match found for instruction
  --> .\dsp56.asm:15:1:
13 | nop  
14 | abs a FOO
15 | abs a
   | ^^^^^   
16 |   

As an aside, having optional arguments for an instruction is relatively common for instruction sets (judging by the admittedly niche ones I use at $DAYJOB), where they can be specified in any order in the assembler but is always in the same place in the instruction and the absence of the flag just evaluates to a default value 0. Even with the above fixed, I'd still need separate subrules for each order. For the DSP56k, it's small enough that I can just add extra subrules for each permutation but is there a good way to handle this cleanly?

@hlorenzi
Copy link
Owner

hlorenzi commented Feb 1, 2025

I've been able to fix this in the new version, so your code above should now work.

Your solution is idiomatic with the syntax we have right now. An alternative would be to split the patterns into multiple rules, and remove the empty pattern in the subruledef:

#subruledef paropts {
    FOO => 1`16
}
#ruledef {
    abs {reg: acc}              => 2`4 @ reg @ 6`3 @ 0`16
    abs {reg: acc} {p: paropts} => 2`4 @ reg @ 6`3 @ p
}

Though, I'd not recommend separating instruction parameters with whitespace alone, since that can trip up the parser in other ways.
You could use a comma, which works best with these split-up rules:

#subruledef paropts {
    FOO => 1`16
}
#ruledef {
    abs {reg: acc}               => 2`4 @ reg @ 6`3 @ 0`16
    abs {reg: acc}, {p: paropts} => 2`4 @ reg @ 6`3 @ p
}

In the future, perhaps true optional parameters could be a more ergonomic solution for all this.
The syntax could look like the following (even though I think this particular suggestion has a few problems):

abs {reg: acc} {[, p: paropts]} => 2`4 @ reg @ 6`3 @ p

@hlorenzi hlorenzi added the bug label Feb 1, 2025
@jmerdich
Copy link
Author

jmerdich commented Feb 1, 2025

Thank you! Commas didn't help this particular case, FWIW, but I'll definitely look into that. I mostly didn't want to muddy the watters by having every subrule in my examples begin with a comma.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants