Emudore: a C64 emulator written from scratch using C++11 and SDL2

Re:Emudore: a C64 emulator written from scratch using C++11 ... by byuu on Wednesday April 20, 2016 @04:20AM (#11532979)

On this topic, I'd like to get the advice of some HN C++ gurus.

In my own emulator (higan), I have a namespace for each emulated system, and each component is its own unique object. Example:

    namespace GameBoyAdvance {
      CPU cpu;
      PPU ppu;
      Cartridge cartridge;
      ...
    }

The obvious downside is that they aren't instantiable. You can only have one instance per process. Generally this isn't a problem for an emulator, but it's still something I don't like about my code.

The obvious "proper" way would be something like:

    class GameBoyAdvance {
      CPU cpu;
      PPU ppu;
      ...
    };

But there's a reason I don't do this: all of the chips need to communicate with one another. So PPU::scanline() may call CPU::raiseInterrupt(Interrupt::VerticalBlank) for example.

So you think something like:

    class GameBoyAdvance {
      CPU cpu{this};  //hooray C++11, this would be
      PPU ppu{this};  //much nastier in C++98
      ...
    };

And now your code goes from this:

    void PPU::scanline() {
      cpu.raiseInterrupt(Interrupt::VerticalBlank);
    }

To this:

    void PPU::scanline() {
      gameBoyAdvance->cpu.raiseInterrupt(Interrupt::VerticalBlank);
    }

Which aside from being a lot of extra typing (seriously, the chips in emulated hardware communicate all the time, all over the place), is also quite a lot slower.

The former can basically get inlined 100%. The compiler knows the exact address of the CPU object, because there's only one. The latter has to go through a pointer to get the address. Even though it's always a constant under actual emulation, the code basically has to account for the fact that you could change the pointer at any time. Even if you tried binding it as a reference, eg CPU(GameBoyAdvance&), the performance penalty remains.

Long ago, I wrote some #define wrappers so I could say "cpu().raiseInterrupt", and depending on compilation flags, it would use CPU cpu; or CPU* cpu; and the results were dramatic: at least a 15% loss of performance just by using the pointer version.

I'd really like the benefits of the latter design, but without the added red tape and performance penalties. But I can't think of any way to pull it off. I really can't afford the performance penalties, as I use 100% of top-end CPUs to try to emulate every hardware nuance possible already. Am I doing the right thing, or is there a better way?

[ Parent | on HN ]

Re:Emudore: a C64 emulator written from scratch using C++11 ... by CJefferson on Wednesday April 20, 2016 @04:37AM (#11533032)

It's a bit horrible and unsafe, but you can use offsetof and some nasty pointer casting to get from a member of a class back to the class. I've done this, and it compiles to extremely efficient code. You can even template a class on the value of offsetof, so you can use the same class as multiple members.

I'm on my phone, so no code examples (sorry). If you want one, reply and I'll write one when I get to a computer!

[ Parent | on HN ]

Re:Emudore: a C64 emulator written from scratch using C++11 ... by kazinator on Wednesday April 20, 2016 @02:39PM (#11536685)

The GameBoyAdvance class could have a constructor which more directly connects together the pieces. The PPU doesn't care that it's inside a GameBoyAdvance: it has a connection to the CPU to raise an interrupt:

   // Don't throw away that simple old C++98 so fast.
   class GameBoyAdvance {
   private:
     CPU cpu;
     PPU ppu;
   public:
     GameBoyAdvance()
     : cpu(ppu), ppu(cpu) // CPU has ref to PPU and vice versa.
     {
     }

So now:

     void PPU::scanline() 
     {
       cpu.raiseInterrupt(Interrupt::VerticalBlank);
     }

Gee, exactly like before, with the namespace. Only now cpu is a member reference to a CPU, inside the PPU object.

[ Parent | on HN ]

Re:Emudore: a C64 emulator written from scratch using C++11 ... by bottled_poe on Wednesday April 20, 2016 @04:45AM (#11533062)

Design Purists Hate Him. Or - How I learned to stop worrying and love singletons. Lose software bloat with this one weird tip. etc.

You know your software better than anyone and you clearly know enough about the design tradeoffs involved. Just try to contain your solution to as few classes as possible.

[ Parent | on HN ]