search

marhel / r68k

A m68k emulator in rust - let r68k = musashi.clone();
MIT License
72 stars 7 forks source link

Consider using a codegen for glue #80

Open emoon opened 8 years ago

emoon commented 8 years ago

I know that this would be a big change but anyway.

In a build.rs script (as it's Rust code being called from Cargo) it's possible to read files and generate new code (can be used with include! macro) and that would reduce lots of the boilerplate that is currently in r68k . Something similar that is in original Musashi.

I know this would be a big change and it might make more sense to go with the current approach first (as it's nearing completion) and perhaps later switch to something like this to reduce the maintenance cost.

marhel commented 8 years ago

I didn't know that. Yes, it could potentially reduce a lot of the boilerplate caused by the need to name everything explicitly. I've been meaning to look into procedural macros as well, for the same reason.

If we had a compact way to specify for each instruction which addressing modes it should support, that'd be great. I think there are just a few classes; "all", "data_alterable" and so on. Or it would even be possible to use the same format Musashi does. In general I'm not a big fan of generating code by string concatenation however, so I kind of like the macro approach in a way, aside from the naming issue.

However, I think you are correct in that it's better to get us to 100% implemented opcodes first, before considering such a big refactoring.

emoon commented 8 years ago

Yeah macro improvements are also on the way into Rust but likely will take a while before they get there.

It's likely possible to do a combo of what Musashi is doing and also use Rust macros to find a good middle ground.

Just to have the names auto-generated (as we know the addressing modes) would be a nice thing (as well as the QC tests and what not)