This project is dedicated to the memory of William Morris (aka Frags), who was the main contributor to the bounty but was unable to see the final result.

Monday, April 16, 2012

Foundations of the House

To show some progress I checked in a massive changeset into the SourceForge SVN that represents the implementation of the following features:
  • Macroblock collection and handling
  • Code generation from the macroblock buffer
  • Macroblocks for many basic high level instructions that are used for the code translation intermediate representation
  • Temporary register allocation/freeing, flushing
  • Emulated 68k register mapping to temporary registers, automatic loading/saving from/to the interpretive emulator Regs structure
  • Compiling of pre- and post-code for the translated block
  • Temporary PPC register, emulated M68k register and flag flow-tracking for macroblocks
  • Basic functions for flag emulation implementation
Sounds quite a big chunk of work, and to tell you the truth it really was. As it seems so far my initial plans are working, the macroblocks are the implementation of the Microcode-VLIW-like approach I explained previously.

What is still missing for your happiness: there is no addressing mode and instruction implementation yet. So, basically this is still not too useful for the average users, thus there is no binary release yet.

But all of these are the foundations of the house and now I can go on with building the walls, which will be much more perceptive: addressing modes and instructions.

Unfortunately, I wasn't able to find the bug that blocks the Kickstart from running, maybe an other Kickstart file might help, we will see.

In the meanwhile enjoy this beautiful diagram of the (oversimplified) method of compiling in this implementation:

Code translation flow diagram
Code translation flow diagram


  1. @Rachi
    Intersting to read.

    Did i understand right, that those red marks mean those still-unsupported addressing mode and instruction implementation ?

    1. I am not sure what you mean on "red marks", but as I wrote in the post: there are no addressing modes and instructions implemented in this changeset.
      The reason is quite simple: what is done already yet needs more testing.
      But I promise that by the end of this month I will publish at least some implemented instructions.

      The fun part of this whole implementation is that it will be usable even if not all the instructions were ready for the JIT yet, because it can substitute the missing ones from the interpretive emulation and everything is still working. (Might not be faster, though, even it can be slower due to the switching between the emulators...)

  2. As I understand it this are macro blocks that can optimized away, because they cancel etch other out.

    1. Yes, that is exactly how it works. For each macroblock the compiler knows the dependant flags and registers and the produced ones. If the macroblocks later overwrite the produced flags/registers and there was non dependant macroblock for those produced results then the macroblock can be removed.

      Petunia in OS4 is trying to do similar optomizations on the translated code, but due to its structure it can only consider the flags, so the end result is not that optimal as it will be for E-UAE.

      Some of you already asked me if it would be possible to fit this compiling engine into Petunia. Since it doesn't usr any of the GPL code, it is possible. However, it would mean that most of the code from Petunia should be rewritten.