You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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:
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:
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):
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.
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.
Provides:
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?
The text was updated successfully, but these errors were encountered: