RBoy: A Gameboy Emulator in Rust

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...

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.

> Software is like writing. It can’t help but express how the author thinks about their code. These tools try to iron that personality out - and for what reason?

A single-author novel can have personality. A 100-author 30-volume encyclopedia, less so. Whenever I set up a new single-author codebase, I set up as little automatic code formatting as I please. For collaborating with other developers, I will enforce as much as possible as early as possible.

I enforce formatters wherever possible after working on codebases with 20+ years of people imposing their own unique opinion on where spaces and braces should go. Worse, arguing about what the spacing should be, and making noisy diffs because people change previous peoples styling.

The formatter has no opinion. It follows rules. It doesn't work perfectly everywhere. It works enough. I would argue caring about exact bespoke spacing of all code is the perfectionism you mention.

> for what reason?

Perhaps you do not remember reading through 10k lines of PHP source that has been formatted by someone who has entirely different ideas about what good formatting is than almost everyone else on earth (or perhaps you never have!), but if you did remember the advantage of a single formatting standard that is ubiquitous would be very clear.

while i agree with you on some parts (ternary operators for example), i love the autoformatters for two reasons:

1. it makes it just plain easier to read others code. it's hard enough to have to grasp the logic behind everything, if they have wildly different formatting on top of that it gets substantially worse (incidentally, this was given as one of the reasons why go was such a success in the open source world).

2. i've been able to get a couple of archaic linter rules dropped, i.e. the brackets around single statement conditionals.

    // for this reason brackets were mandatory
    if (a == b)
        doSomething();
        doSomethingElse();

Disappointed by the downvotes here. While formatters help in most instances, sometimes you should break convention for the sake of emphasis or readability. Anyone here can come up with a good example for themselves. Consistency is the hobgoblin of little minds. Patterns and rules help but no rule should be absolute, judging people's quality of code is like judging people for their dress or their vocabulary. While they are important they are certainly not sufficient for a judge of one's character.

Exactly, that's why e.g. C++ projects have some personality feel while Java codebases feel like all the same corporate bland. Go is meant to be Java replacement in corps, so...

rustfmt does not delete vertical whitespace in that way.

A Z80 backend could probably reuse our static stack allocation, but that's about it. It's definitely useful, but the time-consuming part of writing LLVM-MOS's code generator has ended up being... writing LLVM-MOS's code generator. The static stack stuff is maybe like 250 lines of code, and I haven't had to touch it in months.

You could, but given that even C and Pascal hardly take advantage of Z80, and have to be used as some kind of fancy macro Assembler, better just deal with Z80 Assembly directly.

But then I am biased, having the Z80 opcodes burned in my brain due to the Speccy days.

The Game Boy doesn't use a Z80 though. It's based on a SM83 core, an obscure Sharp design.