[FemmeAndroid]

For those looking to see an example of the match expressions:

https://github.com/mvdnes/rboy/blob/9f6b3bc47311ba687326bfff...

This process of matching on opcode and doing a marginally different version of the same basic few operations on one of a set of registers is something that is _much_ easier to do when you're able to see all the opcodes and activities in a densely packed set of lines like this.

(The start of the opcodes that I linked are not the best example of this, but they get more regular the further down the file you go. See https://github.com/mvdnes/rboy/blob/9f6b3bc47311ba687326bfff... )

Beyond knowing that they exist, I haven't explored macros in rust, but I'm curious if they could be of help here. But using cargo fmt, and spreading each of those lines into 3-10 lines would be awful, and would definitely lead to me making mistakes and not noticing typos.

[paoda]

I can't say much about the use of macros, however there are some SM83-specific patterns you can take advantage of if you decode instructions using octals like what I do in my own gameboy emulator here [1]

[1] https://git.musuka.dev/paoda/gb/src/branch/main/src/instruct...

[tialaramex]

Rust has two flavours of macro. Declarative or "by example" macros, and Procedural ("proc" for short) macros.

Declarative macros might be useful here, at least to cut down on the mindless repetition somewhat. These are fairly hygienic (a technical term meaning that if variable names in the macro are the same as variable names in the code using the macro, this doesn't make them the same variable) and so pretty safe to use but limited.

Procedural macros can do almost anything, they're Rust code that runs inside the compiler when your program is compiled, so e.g. they can have arbitrarily complicated behaviour including completely breaking compilation. You could definitely fix this with proc macros, but, that's not necessarily a good idea.