To sum up what you will get with the new beta: mainly bugfixes. All the features are locked down for the release, the ticket list for release 1.0 is practically empty. I am waiting for any bugs you find before the release. So, please do report bugs you find. But again: it is very important to try to verify the issue before you decide about reporting it. Please follow the steps which are documented in the README file.
Your efforts are greatly appreciated.
JIT compatibility diagnostics
I have rejected a few bugs due to the fact that these programs are not compatible with the current JIT compiling implementation. The reason is very simple: if the program is trying to modify itself without flushing the instruction cache properly then the modified code won't be recompiled and the program will misbehave. Like this program: Where Time Stood Still.
These programs might work on a real processor and still fail with the JIT compiling because the cache handling is not emulated exactly the same how it would behave on a real processor. (Namely: the number of cache lines are much larger than on a real processor, so more code is "cached".)
Although this is not ideal, but for now only a handful of programs are depending on the cache size, so it won't cause too much trouble.
How could you tell that the program is compatible with the JIT compiler?
That is a very valid question. And here is the answer: there is a option for that! (At least there is now.)
I have wasted so much time on chasing errors coming from this issue that finally I have decided I implement a diagnostic configuration option for it. It is called: comp_test_consistency
Usual disclaimer: read the documentation and if you didn't understand what does it do then don't turn it on.
Actually, it is pretty simple: in addition to every compiled block of instructions the compiler also compiles a check which compares the original content of the memory which was used for the compiling to the current content. If it doesn't match then the emulation stops.
Basically, it can be used for verifying if the program misbehaves because it does not flush the instruction cache properly, or there is some other reason.
It is safe to keep it turned on, but it slows down the emulation (sometimes considerably), so use it only when it is needed.
As I already announced in the previous post (couple months ago): the Amiga X1000 optimized version is available in the package. Please use only that version on Amiga X1000, the generic build won't work properly.
Due to the "popular demand" (more than one request ;) I have fixed the cache handling of the emulated 68060 processor type. Please note: it is stated in the documentation from the original E-UAE that the 060 support is not implemented and all I had done was: fixed the cache bits to let the emulator turn on the caches, so the JIT can be activated. However, it is highly likely that there will be problems with some programs running on 060, since other important aspects of the 060 is not implemented (like proper stackframe). So, watch your steps while using it. (And please don't report bugs for it. kthxbai)
ChrisH kindly implemented the support for the betas in RuninUAE. You can turn on the JIT emulation from the menu now. (You guys are too spoiled!) Thanks Chris!
In case you haven't heard: WinUAE is capable of emulating PowerPC hardware through QEmu on intel compatible processors and run PPC apps and even AmigaOS4.
The obvious question: how much better would it be running PowerPC programs on actual PowerPC processor under hardware emulation? :) Probably it would be possible to make use of the native PowerPC processor and it would be fast. Very fast. Not to mention it would open the door for AmigaOS4 running on Macintosh iBooks for example. Do I have plans implementing it? No, sorry. Thanks for asking.
Finally, some thank-you's to the lovely people who helped me in this beta.
Big thanks goes to: MickJT, Mike Blackburn,Chris Handley, Luigi Burdo, Samir Hawamdeh, Raziel and Cass.
Some guys just can't stay away as it seems. :) See you soon.
After I had done some investigation, it turned out that MickJT was right for a long time. We don't need unique changes for Amiga X1000 (for the P.A. Semi PA6T processor), because it is similar to the already supported G5 (PowerPC 970) processor.
So, I have decided that we must not delay the beta for Amiga X1000 any longer. This new build is exactly the same Beta #4 release feature-wise; which was done for the other platforms already. Except that it is compiled for AmigaOS4 with the same minor changes which increase the performance on G5 significantly.
Since the code base is the same I kept the same beta version tag with a postfix. For the first and the last time... Úttörő becsület szavamra! :)
This build is not fully optimized for PA6T processor, since there is no support for that processor target in the AmigaOS4 SDK yet. It is still running much better than the previous generic builds.
Hopefully the PA6T support will be resolved sooner or later in the SDK and then I will add any necessary changes to the E-UAE build too.
In the meanwhile the binary for this build target will be added to the upcoming releases.
Actually, the credit goes to the following good people:
Tobias Netzel - who implemented the G5 support and helped MickJT with advices;
MickJT - who was experimenting with the build for a long time already and pushed me to do this release;
Sven Ottemann & Sebastian Bauer - who helped me with the documentation for PA6T;
Tommysammy - who was kindly doing the testing.
This was a blindfolded build again: I have no access to an Amiga X1000, so I couldn't test the build by myself.
I would like to invite all Amiga X1000 owner to give me some feedback regarding the performance or any issues what turns up with this special build.
You can find my email address at the end of the README file.
Four is a nice, round number. Power of 2, not too many, not too less. You know, four is referring to many good things, like: the Fantastic Four, 4th of July, AmigaOS4, The Magnificent Four... Err.. Maybe not that, scratch that last one.
I had an irresistible urge to RickRoll you guys with the link, but that video has been blocked recently on YouTube in many countries, so maybe next time.
I had my sweet time with a very weird bug related to Quake, which is not resolved yet and probably related to the failure to implement the soft cache flushing. These two tickets are pushed back to Beta #5 for now. Previously I had no intention to do one more beta release before the first Release Candidate, but as it seems I need one more round of testing period.
I had to shuffle around some tickets while I was rethinking the upcoming Release Candidate. You know, changing priorities, agile development, whatnot. What is listed in the milestones now is the plan, although it is not set in (mile)stone... Heheh... (Huh, that was a really lame pun. You should do better than that!)
The idea is: I am going to fix every issue which is known and give you guys some time to test before the final release (candidate).
After a few rounds of pushing and pulling some SAM440/Flex related codes hopefully we have sorted out all the various problems related to those machines. If you were still experiencing issues then please let me know.
Thanks to Tobias Netzel, the flag extraction on G5 is fixed, this will resolve a number of problems with various programs.
The compiling for G5 is still not resolved for MorphOS,
no G5-optimized binary again, sorry guys. If you could tell me how can I
(easily) compile the files for G5 on my iBook then I give it a go, I promise.
As you can see: Beta #5 is coming, there are already a handful things lined up for it.
Please do test Beta #4 and please do report bugs you have found. It is important to sort out as many problems as I could. It is equally important to help me reproducing the bug. So, please read the instructions. Thanks a bunch!
I would like to give a big thanks to Luigi Burdo.
He helped me with a great deal of things, reported lots of bugs and he
is so enthusiastic that he inspired me to keep walking on the road. Thanks a lot, Luigi! Keep up the good spirit!
And, of course, my dearest sidekicks, who just couldn't stay away from the project: MickJT and Tobias Netzel. Cheers!
Also would like to thank the helps, bug reports and overall support to: Samir Hawamdeh, Kicko, Chris Handley, Allan Ullmann.
Ladies and Gentlemen, I would like to have a word with you about bug reporting...
Please do not report E-UAE JIT compiling related bugs to:
a forum at your favorite portal(because they are going to give you advices, unless it is a cooking portal, but they won't fix it anyway);
your "friends" on Facebook as a status post(because your hot ex-classmate doesn't care, not to mention that she put you to the acquaintances list for a long time and I am prettty sure she won't fix it anyway);
Runinuae author(because although Chris is a good guy, almost certainly he won't fix it anyway - hey Chris!);
your fellow Amiga-enthusiasts at the Club(because they might listen to your theory on what is the root cause of the bug, but they won't fix it anyway);
your neighbor's cat(because the poor thing doesn't want to hear anything about "fixing", I guarantee).
Why? Quite simple: if you try to report bugs anywhere else than my mailbox there is zero guarantee that your bug report ever lands on my computer.
You know, there is some chance that I wake up one day and realize:
Ah, some Amiga-fan while playing Superfrog on level 6 encountered a graphical glitch which is caused by a mis-used flag dependency in the JIT compiler optimization, so I must fix it. I need coffee!
Yes, there is some chance, very-very-very low chance. (As opposed to there is high chance that I wake up one day and realize: Hrrgrhh... I need coffee!)
If you want to get the bug fixed then report it to me, preferably by e-mail.
I held this release back for a while just to fix the emulated cache checksum feature, but I have been chasing a bug for two weeks without any success. So, that fix is postponed to the next beta, in the meanwhile you can enjoy some significant speed enhancement and increased stability.
Without going into the details regarding the changes (see the included README for all changes) I would like to mention the most important change:
The major feature of this beta release is the register and flag optimization fix. You can turn it on in the configuration, just set comp_optimize to true.
If you are interested in the details I explained it already how the optimization works in an earlier post, but in case you are too lazy to read through that post: here is my old diagram (just because it is beautiful, you know):
Code translation flow diagram
Let me summarize it for you: the JIT compiler is collecting information about data-flow dependencies between the various macroblocks and tries to remove the ones which won't have any effect on the outcome of a certain block of macroblocks.
This is not a new feature in the JIT implementation, but previously a few (tons of) bugs prevented it from working on more complex codes than my Mandelbrot test.
In this release I have fixed every issue I have found so far with the optimization and it seems working quite nicely. You can boot the AmigaOS and it runs just fine, also games and demos will benefit from this feature too.
I was planing to do a comparison video where the speedup is clearly shown, but I haven't had too much time yet, so this is your job now, dear EUAEPPCJIT fans! Just post the links to the videos into the comments here. :)
PPC970 aka G5
Not everything is sunshine and happiness, though. Supporting G5 processor architecture target turned to be much more complicated than I thought, especially because I don't have any hardware to test on.
In the previous release the MacOSX G5 binary was not working properly on G5 (neither on any other PowerPC as matter of fact). Thanks to Luigi Burdo for the report and Tobias Netzel (again) for the help with the compiler. This is fixed in this release, hopefully. (Fingers crossed, I still don't have hardware to test on.)
While the situation with the MorphOS G5 version is not that hunky-dory: as it seems there is no official compiler with G5 support yet in the MorphOS SDK and it is rather complicated and unreliable to compile any source for that processor. Until this situation is improved the G5 version for MorphOS won't be available from the beta binaries.
However, nothing stop you from compiling your own version from the sources, as these are always available at SourceForge.
As I mentioned: I postponed the fix for the block checksum to the next release and also picked up some things to do. You can find the planned list here: