I have good news and not-so-good news

Which one should we start with? Okay, let me choose for you: not-so-good news first.
At the moment (beside the yet unimplemented instructions) there are two bugs that prevent the OS from running properly:

For some unknown reason when an instruction reads and then writes the memory then the Kickstart goes back to the well-known reboot loop (actually it is a crash, sometimes you can even see the Guru message).At the moment I don't have the slightest idea why this happens. I traced it back to the normal MOVE instruction, when it copies data from one address to another. There is nothing wrong with the instruction implementation itself - as far as I can tell. So, this is some weird sh*t again. Lovely.

When the optimize flag is turned on (comp_optimize = true in the config) then the Kickstart crashes very early.To tell you the truth, I am not surprised. When I tried to figure out the register dependency for each macroblock for each instruction then sometimes I mixed up stuff what I found later on. Due to the wrong register dependency settings for some macroblocks,
these were accidentally removed, so some code is "optimized away". Most likely there are more mix-ups and missing dependencies in the code, it can be found just matter of time.

Good news:
As you can see in the last item for the update: I temporarily disabled the two already implemented instruction which tries to read and write the memory. The missing instructions are substituted by using the interpretive instructions.
Now, if you disable the optimize option in the configuration (comp_optimize=false) then the Kickstart seems working with some actual JIT compiled instructions! YAY! \o/(I guess.)

Some more interesting problems

I have got some feedback about issues with running Kickstart 1.3 and some old Amiga500 games when the JIT is enabled. This is interesting indeed because if even if the JIT was turned on it did not emulate these old codes because the cache is never turned on (there was no cache in the Motorola 68000 processors when these programs were written).
As you can read it in the FAQ: the JIT compiling is depending on the cache emulation heavily. So, this is one more question mark. I haven't had much time to investigate it yet.

But most importantly: the Summer Sun is shining, let's go surfing! (Oh, wait. I don't do surfing. Last time when I jumped onto a bodyboard on the beach I bruised my ribs. Embarrassing and totally geeky. Let's just surf the net, shall we?)

20 comments:

In other words, we can just set comp_optimize=false, and with enabled JIT try to load some AGA/020 games, to see, if there will be already any differences in speed just because of all the other implemented instructions. By logic should be, as from all your blogposts i see there was a lot of instructions which already implemented even if not take in accoun those read/write ones.

There is no reordering of the executed instruction parts (PPC instructions) or parallelization of the execution in the compiled code, so that should not be a problem.The memory access is not an atomic instruction, like in a normal compiled code, because it has to go through the virtualized memory banks and the custom chip emulation.

I'm not able to get to the main kickstart (3.1) screen; there's a whole lot of warnings and errors in the shell output, though I managed to get Lion King going after a few recoverable alerts. It is slower with the JIT on. Perhaps that's to be expected at this stage?

It is possible that some programs might run slower right now, because of the missing instructions mostly. If the compiled instructions are not faster than the interpretive then the overhead of the JIT cache handling and everything else slows down the execution a bit.

Regarding the 3.1 Kick: as it seems you have to have the bogomem (slow "fast" ram) turned off for some reason. I need to investigate why.

With it (together with other options which i have for that game) i have red guru. But if i comment out "cachesize=8192", then game starts , through dunno if jit is working in that case (i assume not, because the speed of game 1:1 the same as without JIT).

There is config which i use now to play with your last version: http://kas1e.mikendezign.com/temp/AladdinAGA.rc

Try to turn on the constant jump, although at this stage this should not matter at all:

comp_constjump=1

Probably there are some (more) bugs in the emulation yet, so I am not surprised that Aladdin didn't work.If you remove the cache size line from the configuration then you effectively disable the JIT compiling: without specified cache size no code cache allocated, the JIT compiler cannot run. It falls back to the interpretive, this is why the game worked again.

If you check the output in the console you should see this message when the JIT activated:

"JIT: Change cache emulation: enabled"

If you cannot see these lines or it says "disabled" then the JIT is not active at the moment.

There is also debug output for the compiling, if you were really interested in whether the JIT compiles something at all. You can turn on by setting the JIT debug log on:

comp_log=1

But be prepared: tons of compiling log will be dumped into the console. You might want to retarget it into a file. In this log you can see the following lines:

I do tests of some more games (they all aga/020 of course), over whdload and as plain adfs, with configs which works ok without enabled jit, just with adding necessary jit block (from faq) + i check them to avoid dubles of the same option twice (so jit related options always as they should).

So, WHDload ones: always red GURU loop for all of them. At least i tryed 3: Aladdin, CoolSpot and LionKing. Shell output from them always the same, and red guru from them always the same as well, so i assume that currently whdload can't works with current JIT. There is configs which i try for those 3 games, and their shells outputs: http://kas1e.mikendezign.com/aos4/jit_tests/whdload/

Then, i tryed just ADF versions (i.e. the same configs, just with no whdload, or any other hdfs/partitions/et, but plain ADFs instead). So far, there is much more interseting happens:

brain_the_lion: just works. Through i see visually no differences in speed in game itself.

aladdin: it starts, bring me 2 yeallow windowses, i can skip them, cracktro starts (from "prodigy" one) and then nothing seen, but music plays, game can't starts. But at least no red gurus.

superfrog: intro starts, all seems to works, when do "access to disk" to load game itself, just nothing happens for long time, and nothing new in shelloutput.

There is configs and shelloutputs from: http://kas1e.mikendezign.com/aos4/jit_tests/whdload/

btw. Is there any differences for JIt if i will set it as 68020 or as 68ec020 ? (in all my uae configs without JIT i use all the time 68ec020).

As it seems next to nothing working yet, unless somehow the JIT gets disabled... :)The only difference between 68ec020 and 68020 processor is the 24-bit address bus instead of 32-bit. For the JIT this shouldn't matter, but I see no point in selecting 68ec020 instead of the 68020, unless there is some weird compatibility issue in the program.

While I checked the bogomem issue I had found very strange behavior: an instruction is writing into one of the read-only custom registers. But that instruction is a read instruction and emulated by the interpretive, so this makes no sense at all.

But at least few adf games works, and we at last start to test something :) I.e. all your code (even if it have bugs for now) already in, and trying to work. Lately we can just get let's say "brion the lion" (i.e. that one which already works as ADF one with enabled jit block), add comp_log=1 and see what happens with and why there is no speed differences.

I mean even if it feels that there is next to nothing working yet, the real and major part already done from your side and now fun time of lovely bug hunting starts :)

ps. in previous post i said that configs and shell outputs in wrong location, there is right one: http://kas1e.mikendezign.com/aos4/jit_tests/plain_adf/ (i.e. for whdload ones jit_tests/whdload/ directory, for adf ones jit_tests/plain_adf/).

As it seems to me that game doesn't enable the caches, so it is executed by the interpretive emulator. Maybe I could implement some indication on the screen if the JIT code is really running. In this case we can be sure, at least.

I have a few things where I can start debugging, it just so much time...

And game actually starts ! But sadly to say, speed is the same 1:1. Maybe even a bit slower, but 100% not faster. While, as i understand if we have in output last words with "enabled", then JIT should works..

Thank you, works much better with this settings.When I use Kick 1.3 it also sais: "JIT: Change cache emulation: enabled".But I am not sure if it's used. When I change the settings, I will get a Guru. If I change them back, I still get the Guru...But now I am much more confident :) Thank you.

I am not sure why that happens. The logic for enabling JIT is: JIT enabled in config, processor is set to 68020 or higher, caches enabled.Maybe the Kickstart does not turn on the caches for 68060. If you start the setpatch then maybe that will do it.