- Implementation of
- AND.x reg,reg;
- EOR.x reg,reg;
- EOR.x reg,mem;
- SUBA.x reg,reg;
- SUBA.x #imm,reg;
- BSET.L #imm,reg;
- BCLR.L #imm,reg;
- EXG.L reg,reg and
- NOP :) instruction.
- Reorganized MOVE.x mem,mem instruction: memory reading and writing is separated out into independently callable functions to support the implementation of other similar instructions.
- Implementation of OR.x reg,reg instruction was adapted to a more generic form.
- Fixed flag checking for AND(I).(W|B) #imm,reg instructions.
- Removed confusing OR immediate macroblock and replaced by the already available OR low immediate.
- Falling back from addressing mode d16(ax) to (ax) if the offset is zero.
- Fixed depenency flag handling in result check helper function.
- Cleaned up opcode description table. Removed instructions from the table and from source code which won't be supported by the JIT compiler. Added missing RTM instruction.
- Temporary register storage slots were moved from the stack frame to the Regs structure (context).
- Removed useless debug log that flooded the output.
- Temporarily disabled MOVE.x mem,mem and EOR.x reg,mem instructions to let the Kickstart run.
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.
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?)
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.
ReplyDeleteAny possibility of out of order execution causing a problem here? Like the write being reordered to be executed before the read?
ReplyDeleteThere 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.
DeleteThe 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?
ReplyDeleteIt 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.
DeleteRegarding 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.
@Rachy
ReplyDeleteI tryed to run AladdinAGA via your latest updates (MickJT build a binary), and in my config i added this (is it right?):
enable_jit=yes
cpu_type=68020
comp_optimize=false
bogomem_size=0
cachesize=8192
comp_constjump=0
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
Maybe there is something else need to be disabled/enabled as well ?
Try to turn on the constant jump, although at this stage this should not matter at all:
Deletecomp_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:
"JIT: Comp: ..." - these are the compiled instructions.
@Rachy
DeleteI 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... :)
DeleteThe 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.
So, there are bugs, definitely.
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.
DeleteI 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/).
DeleteAs 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.
DeleteI have a few things where I can start debugging, it just so much time...
@Almos
DeleteIf you mean brain_the_lion, then yep, i see that it firstly bring a lot of:
JIT: Change cache emulation: enabled
JIT: Change cache emulation: enabled
JIT: Change cache emulation: enabled
....
And in the end by some reassons (when game actually starts):
JIT: Change cache emulation: disabled
And then yep, its all seems going on without jit and visually in game later we see no differences..
@Rachy
DeleteTryed another ADF version of AGA/020 game: Kid Chaos:
Yellow window on running after bunch of JIT: Change cache emulation: enabled
----
Recoverable Alert. Press left mouse to continue
Error: 0100 000f Task: 00213ff0
----
4 times in loop, then "cracktro" starts: music plays all seems ok.
Then:
....
JIT:Change cache emulation : enabled
Programm uses Copper SKIP insturction.
Illegal instruction: 4afc at 0002cf32 -> 0002cf34
JIT:Change cache emulation: disabled
JIT:Change cache emulation: enabled
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..
On MorphOS also Guru on 3.x, with 1.3 reboot loop. No chance to get it working yet.
ReplyDeleteI tried several CPU and chipset settings.
Check out the FAQ, I added some guidance on the configuration:
Deletehttp://euaejit.blogspot.com/2011/11/while-you-are-waiting-faq.html
Thank you, works much better with this settings.
DeleteWhen 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.
Please check the FAQ: I added some Q/A regarding the 1.3 Kick too. Basically, it is not compatible with the 68020 processor.
DeleteWhen I switch to 68060 it seems that JIT is disabled. Is this intentional or doesn't the kickstart turn on caches with this CPU?
DeleteI 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.
DeleteMaybe the Kickstart does not turn on the caches for 68060. If you start the setpatch then maybe that will do it.