Wow - the Baader–Meinhof phenomenon must be real. I think the only place where I’ve allowed a bit of complexity in rather than sticking with the simplest implementation is the GPU - the simplest approach is to render all of the GPU memory to the screen once per frame the slightly more accurate approach (which I do) is to render one row of pixels at a time (so that the CPU can tweak settings mid-frame to achieve parallax effects) the real hardware is quite a bit more complicated, but the medium-complexity approach works perfectly for nearly all the games I care about, and only has minor glitches for cases where it’s wrong. In all cases the architecture of my emulator is very basic - no JIT, no worries about sub-CPU-cycle timing being accurate, etc just a loop which reads an instruction from memory, has a big `switch` statement to decide how to act upon that instruction, and then goes back to read the next instruction. Things would have gone much faster if I’d started here :) Third, I discovered which is an open source documentation project which has been bug-fixed and kept up to date and is generally much higher quality than the PDF I started from. (In this case the error code is just “this instruction is implemented wrong”, without saying what’s wrong about it - but with the gameboy having a fairly simple CPU where the vast majority of instructions map to a single statement in a high-level language, it’s good enough for most cases) Initially I was using a fairly-well-known PDF which explained the gameboy hardware with 90% accuracy, and focussed on just getting the CPU working to a point where it could print “hello world” to the link cable port.Īfter that, I discovered that some people had written test ROMs - given only the most basic CPU instructions being implemented in a mostly-correct-ish way, these ROMs exercise the more exotic instructions, and edge-cases of the common instructions, and print out an error code if the emulated CPU gives results that differ from the physical CPU. It’s also probably worth comparing module-by-module - like for all languages, the CPU implementation does pretty much exactly the same thing in exactly the same way but for command line argument parsing, every language is very different. If somebody wanted to go to the effort of counting logical statements per language, I’d be interested in seeing what that looks like :) (which adds up quite a bit when multiplied by 500 CPU instructions) Zig / safe : Emulated 40 frames in 10.00s (4fps)Ĭ++ and Rust contain (incomplete attempts at) emulating the sound chip - the other languages just have an empty stub (I want to get at least one implementation working properly before using it as a reference to write the others - interestingly both of those implementations, despite being written based on the same specs, sound wrong for different reasons…)Īlso I wonder how it counts “lines” - if it is literal newline characters, then probably the biggest factor there is that some languages insist on having a newline after each case in a switch statement and some don’t - so in the CPU implementation some languages are like Py / release: Emulated 101 frames in 10.06s (10fps) Php / release: Emulated 255 frames in 10.01s (25fps) Php / opcache: Emulated 613 frames in 10.01s (61fps) Py / mypyc : Emulated 887 frames in 10.01s (89fps) ![]() Rs / debug : Emulated 1676 frames in 10.00s (168fps) Nim / debug : Emulated 1968 frames in 10.00s (196fps) Pxd / release: Emulated 3792 frames in 10.00s (379fps) Go / release: Emulated 5040 frames in 10.00s (504fps) Nim / release: Emulated 6161 frames in 10.00s (616fps)Ĭpp / debug : Emulated 5693 frames in 10.00s (569fps) Nim / speed : Emulated 8127 frames in 10.00s (812fps) ![]() Zig / release: Emulated 8792 frames in 10.00s (879fps) ![]() The same gameboy emulator rewritten in C++, Go, Nim, PHP, Cython, Python, Rust, and Zig (and WIP typescript) mostly to teach myself the languages and to compare and contrast their idioms.Īlso, when taken with a very large grain of salt, usable as a language benchmark (As with all benchmarks, there are lots of caveats - but as far as I’m aware this is unique in being “the same code in multiple languages” and “several thousand lines of code”):
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |