Bug with rules passing arguments to other rules about customasm HOT 1 CLOSED

While I've managed to resolve the issue with %r0 and $0x1234 to stop them being interpreted as a number literals, the issue in general is going to be more difficult to solve.

If you use it like mov %r0, $1234, then the tokenizer would see $1234 as a single token for a hex number literal, because it's a valid hex number. But then ${imm: i32} would fail to match, since it's expecting at least two tokens, one for $ and the rest for the expression.

For this to work as intended in every case, the instruction matcher would have to re-merge the stream of tokens and break them apart at a different spot, reinterpreting the stream of characters as it works on each instruction with more context. I think I'll leave this as an exercise for the future.

Is it possible that you change $ (and even % perhaps) to different tokens in your instruction set? It would avoid future ambiguity issues with number literals.

from customasm.