Are you excited? I bet you are. In the meanwhile download and enjoy the new beta:
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.
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.
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.
X1000
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.
060
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)
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)
RuninUAE
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!WinUAE PPC
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.
Thanks
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.
Good work!
ReplyDeleteThanks! :)
Delete