- Implementation of flag condition "addressing" modes.
- Implementation of ST.B Dx, SF.B Dx, Scc.B Dx, ST.B mem, SF.B mem, Scc.B mem, PEA.x, MOVE.x #imm,mem, CLR.x Dy, CLR.x mem and LEA instructions.
- Fixed BTST instruction: testing bits higher than 15 was wrong.
- Merged multiple condition code-related lines in the 68k instruction descriptor table.
- Removed unnecessary parameter load for cache_miss function from the translated code PC verification code.
- Added cache miss check for normal execute handler.
- Code cleanup: removed the TODO label from immediate addressing modes used as destination and added meaningful error message instead.
- Removed ignored parameter from the unsupported opcode macroblock push function.
This important change opens the gate for the conditional branching instructions (Bcc and DBcc), that are essential for any average loops and iterations. For now only the conditional set instructions are implemented, because it was much more easy to test these.
I also took some weekday nights for dealing with some simple instructions, like LEA, PEA and CLR. On the working days I am too tired, this is all I can afford.
There is still no fix for the OS booting issue. I have tried to trace it again, at least now found out it is not about the simulated cache manipulation, because there is no cache-incoherency detected. I am still puzzled by this whole problem.
Go Álmos go!
ReplyDeleteCan't wait to see the full jit @ work.
Solving the OS booting issue must be priority 1 right now?
ReplyDeleteYes, that is the most important thing. I spent half of my time on that again, but it was a fruitless struggle again. It was too frustrating, so I spent the other half of the couple hours I had on implementing something instead.
DeleteSince I ran out of ideas, I will try the impossible: remove every external interaction and log every executed instruction for the interpretive and for the JIT which is calling the interpretive functions. Probably together with the changes on the registers and flags. Then compare the two enormously huge files with some tool that I can come up with. It takes a lot of time to set this up which is why I haven't tried yet.
Especially removing of the external influence on the processor emulation is really complicated, if it was possible at all. Without that the order of the execution of the different parts of the Kickstart varies for every start, which makes it impossible to compare the results.
I assume you've tried the obvious, which is removing everything relevant, then adding bits 1 by 1 until it breaks? -MickJT
ReplyDeleteI tried to remove whatever I could. I managed to remove everything else than compiling simple branches to the interpretive instruction functions instead of calling them in a loop and the code cache look-up mechanism remained the same. I saved all the registers before executing any compiled code and restored before every C function calls. It cannot be simpler than this. I even manipulated the calculated processor clock steps to be exactly the same as it is in the normal loop. (Not that it would matter much.)
DeleteI don't have the slightest clue why this is not working, basically it is equal to the normal loop which calls the instruction functions, except that the loop is unrolled into a series of calls.
What I might try: I could check the integrity of the executed code block, in case the OS is copying some self-modifying code into the RAM, but I highly doubt that since the instruction cache is on and there were no cache flushing (without flushing it wouldn't work on a real machine either).
"in case the OS is copying some self-modifying code into the RAM, but I highly doubt that since the instruction cache is on and there were no cache flushing"
DeleteThe OS should be doing quite some cache flushes during boot process from very early on when doing things like building library jump tables.
The OS is certainly doing cache flushes, but if that memory area wasn't executed before then it is not in the compiled code cache yet. Instruction cache flush is throwing away the whole compiling buffer for now, so this shouldn't be an issue.
DeleteIn the meanwhile I have checked the integrity of the compiled code chunks, everything seems fine.
I think you need to make a test case, like you did whit the fractal code.
ReplyDeleteMaybe, but what can I test? It should be sufficiently complex to the ROM boot process at least.
DeleteIf you had any ideas, like a demo that does not use any OS functions with source code available or something similar then let me know.
What about the AROS kickstart replacement?
ReplyDeleteIs that supposed to work with E-UAE? I have never tried that yet.
DeleteIt seems it should:
ReplyDeletehttp://en.wikibooks.org/wiki/Aros/Platforms/68k_support#UAE_E-UAE
Ok, I give it a try. No high hopes, though.
DeleteCan't get it to work in E-UAE. With JIT turned off it just keeps resetting and with JIT turned on it stops at some point.
DeleteAROS kickstart would be very nice for debugging as it's source code is available and can be built using gcc.
The only AROS kickstart I got working is the FS-UAE builtin version. FS-UAE didn't work with other AROS ROMs.
Well, E-UAE is not perfect... :)
DeleteAny progress? Been 3 weeks now and santa wanna know if he is going to be able to play whdload games this year with JIT? ;)
ReplyDeleteThere is not much to report, no visible improvement yet.
DeleteI started to implement what I mentioned earlier: collecting the full debug log of every executed instruction. It is saved into a file, while the Kickstart reaches the insert disk screen it grows to a roughly 300 MB binary dump.
Since this debug dump is not human-readable I also created a tool that can be used for comparing the debug dumps, parsing them and listing the registers and the executed instructions around the differences.
There is one problem though (which could be foreseen): right now every time I start the emulation it creates a slightly different log, due to the emulated environment (like mouse movements, timers, hardware speed, etc.)
Now, this could be eliminated but it takes a while to figure out what "entropy collectors" are fed to the emulation and get rid of them without stopping the OS from booting.
I am working on this right now. As soon as this problem is solved I can compare the interpretive execution with the JIT translated one and see where the difference is exactly. Of course there is no guarantee whatsoever that I will be able to track down the bug by this method, but I don't have much choice at the moment.
Real hardcore ..
DeleteBtw, Almos, i am sure you know it and think about it already, but maybe it will worth to contact with let's say winaue jit author , and talks about those problems, maybe he as someone who already making jit (thorugh x86 one), can help somehow ?
I thought of that before, but I doubt they could help me. My implementation is significantly different than the x86 version, not to mention that it might be related to some register usage on PPC or similar problem.
DeleteAnyway, it might be a good idea. No high hopes though that they would reply.
Its mostly one man works on it : Toni Wilen, and he is pretty active today still (he also make a lot of stuff for AROS, to make it works on 68k/winaue), so he seems kind of person who know the roots and can be good just to talk about problems. He also active on eab.abime.net, so the chances are high to find him out :)
DeleteThanks, I will drop him a few lines.
DeleteHow did it go?
ReplyDeleteI asked Toni Wilen as kas1e suggested, if he had any idea. He replied immediately and gave me some hints where to look.
DeleteI have got nowhere yet, haven't had too much time either. Luckily, the Xmas holiday season is coming... :)
Lets hope you solve it so we can have something to play with during christmas :)
DeleteHello,
ReplyDeleteany news there?
Not just yet, but getting closer. :)
DeleteI.e. OS is almost booting or at least no reboot-loop anymore ?:)
DeleteI have fixed lots of bugs, yet there is work to do. But at least I have a clue now what is going on.
Delete