Giters

shish / rosettaboy

A gameboy emulator in several different languages

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

C implementation

jbboehr opened this issue · comments

commented

I noticed there wasn't a pure C implementation, so I experimented with porting the existing c++ implementation. It was fairly straightforward as the existing c++ implementation doesn't currently really use any but the most superficial features of c++ (which is fine, of course).

I went a bit overboard reordering function definitions to avoid forward declarations, but in most cases the diffs would've been fairly minor.

I was wondering if you had any thoughts on the matter.

For reference: master...jbboehr:rosettaboy:c99

There are a few things left to do:

  • double-check exit codes
  • write a --help
  • might be better to have *_ctor not return by-value
  • could use setjmp/longjmp instead of just calling exit in the error handlers
  • cleanup BEGIN_EXTERN_C/END_EXTERN_C
  • could re-order functions to keep it in the same order as c++, but then would need forward declarations
  • rename from c99 to c?
  • update README
  • totally didn't run clang-format on any of it, whoopsies

I noticed in gpu c++ always access ram through cpu (ex) which seems like an unnecessary level of indirection. Not sure how well it's optimized away, but in my mental model that makes for an extra pointer deref per ram access. I changed it in my branch.

commented

Having a pure C version seems totally valid - it'd be even nicer if the C++ version was more C++-ish, to compare the differences there (but I'm not a C++ expert, and with my limited knowledge I didn't see any opportunities for C++ idioms beyond "C with classes"; ie, it's hard to demonstrate memory management features when the whole app uses statically-defined fixed-size arrays)

I think one of the other languages (nim? zig?) already uses re-ordered functions to avoid forward declarations. Personally I think it makes most sense to start at the high level (eg tick()) and have the internal implementation details below it in the file, but I've not been strict about that if there was any reason to do differently.

I forget if there was ever a good reason for accessing ram through cpu in the past, but yeah I'm pretty sure that it's redundant now :)