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.

Tuesday, May 1, 2012

Deep-diving into memory

Since I just bought a new SSD and I am about to reinstall my laptop, it is time to do another update on the project: another batch is uploaded to the SourceForge repository. (I hope I won’t lose the sources… ;)

So, what was made into this update? A quick list about what happened in the last two weeks:

  • Direct memory writing support
  • Detecting of special memory accesses per instruction and calling the chipset emulation on memory writes from the compiled code
  • Implementation of some instructions:
    • ADDQ.L;
    • MOVE.x register to memory;
    • MOVE.x register to register;
  • Implementation of some addressing modes:
    • immediate quick, like: ADDQ.L #x,reg;
    • indirect addressing with post increment, like: MOVE.x reg,(Ay)+;
  • Misc fixed stuff:
    • proper logging for JIT (with a new configuration item: comp_log);
    • slightly reworked temporary register handling;
    • better handling of reloading/saving of flags and the base register;
    • reloading of the emulated PC before leaving the compiled code is added (probably this was responsible for the reboot-loop at booting the OS, see below).

The most important change was the handling of the memory writes. When I started to plan the project this was one of the concerns: how to figure out which memory access requires special handling and which one can hit directly the emulated memory. By overcome of this issue all three problems are resolved:

  • memory accesses are emulated as it is needed;
  • self-modifying code is handled by using the processor cache;
  • translated code lookup is managed by simulating the cache lines.
Luckily, the x86 JIT implementation already solved this issue (too): every instruction is executed by the interpretive emulator first for a couple times to prevent unnecessary translation of the code pieces that won’t be executed often (like initialization/cleanup code). While it is doing that it collects some information about the executed code that can be reused for the translation. One of these is the memory access type. Very clever solution, I must admit.

I am still chasing the ghost-bug that prevents the OS from booting. The recent fixes for the PC register (program counter) reloading changed the behaviour. Instead of running around in a reboot-loop, the OS is waiting for something to happen, most likely some hardware to trigger something. So, it is still no good, but looks a bit better.

Where to go from here: more addressing modes and instructions will be implemented before I start working on the implementation of the optimizing routines. First, I want to make sure that most of the Mandelbrot test is executed using compiled code, thus it will be easier to test the optimization and finally we can see how better the JIT performs than the interpretive. Exciting!

You have probably noticed that the state of the project on SourceForge is still pre-alpha. I don’t want to change it while the OS cannot be run on the emulation, so this is the other important goal.

So much for today. While you are enjoying the sunny, warm summer, don’t forget about us who are suffering from the cold, rainy days: Winter is coming… :/

6 comments:

  1. I'm loving these updates. I confess I only have an 80% understanding of everything that you speak of here, but I truly find your progress exciting.

    I appreciate the detail you're providing in these updates and really feel like I'm along for the ride :D Good job.

    ReplyDelete
    Replies
    1. Thanks for the cheering. I am trying to be as understandable as possible, but sometimes what was obvious to me is not as trivial to anybody else.

      Just let me know if something was unclear and I do my best to explain.

      Delete
  2. Embrace your code (+ the machine) and you will feel the warmth. ;-)
    Btw, thanks for updating the blog, it is great stuff to read. Grtz, Dirk.

    ReplyDelete
    Replies
    1. Thanks. Yea, maybe I will do full recompiles more often just to warm up the laptop case. Or I finally give up fighting the facts and just undust the heater... Man, do I hate winter? :-P

      Delete
    2. If it helps... It's not all sunshine and lollipops up here. But being experienced in both hemisphere's, your heater should never be too far away :)

      I do find late-night coding to be far more enjoyable in the midst of a nice heatwave though. We're not getting one of those any time soon :-/

      Delete
    3. @Álmos Rajnai
      Winter is perfect for you then you can code all the time and keep you warm :-)

      Delete