Improve JIT compatibility

[amyren1966]

JIT seem to break compatibility also for system friendly applications. I notice this specially for programs made with Hollywood. RNOpdf is one example, as the script will fail (stack overflow) if launched when JIT is enabled. Also games made with Hollywood does fail, or act strange if JIT is on. This is the case for one of my own games, Runaway. They run fine when JIT is off, but quite slow. For comparisation, these apps and games does run fine on WinUAE with JIT.

So the feature request is as described in the title.

[midwan]

@amyren1966 Thanks for reporting this. I also have a few Hollywood apps I can test with, so have a scenario to recreate this with.

Normally it's TomB who's doing the JIT and low-level work, so if we can have a scenario to recreate the problem, I can open an issue with him afterwards. ;)

[midwan]

@amyren1966 My Hollywood apps didn't seem to have a problem with JIT.

I'm assuming you're referring to this RunAway game? http://os4.aminet.net/package/game/wb/Runaway_OS3

I could run it normally in my installation, what kind of unexpected behavior did you notice?

[amyren1966]

If JIT is on, the searchlight will stop moving after a while, and stay on just beside the position next to the barell. I guess that the sprite hangs at this position, while the real position is towards the barell. The player can now pass the light without being detected. Also the two guards will stop moving at certain positions. That is, they do move, but the sprites freezes at certain points for a while.

One of my other Hollywood game, donkey kong does work normally, and also one other Hollywood app I did try. But the RNOpdf app does crash for me if JIT is on. Did you try that one?

[midwan]

@amyren1966 I just tested RNOpdf with the Hollywood.pdf file (3.84 MB), on my AmigaOS 3.1.4.1 installation:

• The 68k version worked normally
• The FPU version showed an error (stack overflow) as you described.

Can you confirm the same with the other Hollywood apps you've tested with?

[midwan]

I've opened an issue at Tom's repo about this: https://github.com/PandTomB/uae4arm/issues/7

[amyren1966]

I confirm that non-FPU version of RNOPdf starts up when JIT enabled. FPU version will fail with JIT.

But my Runaway game is not compiled as a FPU version, and it will not work properly when JIT is enabled. The easiest way to spot this is by launching it, and wait. The searchligt will start moving, from the right side to the left, and then turn back. It will then stop before reaching the right side. If launched with JIT turned off it will continue moving.

Also I did test my other game, Donkey Kong (also an LCD conversion). This does not use FPU either. It will lauch and you can start playing. But if you start it (press "1" on the keyboard, or press the A button), then move 3 to 4 steps to the right, and then step back to the left using the arrow keys. The player will stop moving at one point, and the barells will pass you without generating a miss. Do this immidiately after pressing "1", then you should be able to test it without getting hit by the barells (or else you might just jump over a few barells first and wait until the path is clear). If JIT is disabled, the player will move as it should.

By the way. This is on OS3.9, 68030 / AGA chipset, but running on a P96 screen. I also tried testing it with 68020, same thing.

[midwan]

Thanks! I also noticed that disabling JIT FPU doesn't make a difference, so the problem is somewhere in the main JIT code, not the FPU specific part.

Let's give Tom some time to look into this.

[andiweli]

I don‘t know if it‘s the same issue, but playing Jim Power gives me sprites on wrong positions and faulty collisions. Playing without JIT seems to be correct but hell slow and sound stuttering.

[midwan]

@andiweli Games and JIT are usually not a good combination, though there may be some exceptions (those that don't use the custom chipset but really want CPU power). Jim Power is kind of a special case, works normally on the RPI4 but on lower powered systems it works properly only with frameskip.

[midwan]

Fixed with e0cd52cf2fecf7e6b55d0e76907dd4881f40efdf

[amyren1966]

I notice this issue have been closed. But I still encounter the same issues with JIT enabled. Is this covered by another thread?

[solskogen]

What kind of issues do you encounter?

[midwan]

@amyren1966 I assume you're referring to the Hollywood made games mentioned above? If so, let's move those in a separate issue please, as the original mentioned here was actually fixed with the commit above. Looks like we're not 100% bug-free on the JIT engine yet! :)

[amyren1966]

I am not sure what you refer to by "original mentioned here was fixed"? In the first post in this thread I mentioned two examples, RNOPdf and the Hollywood games. I just tested the FPU version of RNOPdf, and it still fails with the stack overflow error, and the game mentioned also still fails. I can make a new issue for this if you prefer, but it will still be the same issue as reported in this thread. Or did you test the RNOpdf FPU version successfully with JIT now after the fix?

[midwan]

I was referring to the RNOpdf tool which was originally reported having the problem. After the JIT fix mentioned above, I could test the tool and I didn't see the problem anymore. Perhaps I missed something however? I only tested this on 3.9, not on 3.1.4.x, so if the issue only occurs there, then we can revisit it.

[amyren1966]

I am on OS3.9 also. RNOpdf comes in two editions for OS3, one compiled for FPU and one plain 68k. It is only the FPU version that crashes. I tested with version 1.3 from aminet.net. This is the same version that was available when I wrote the first post. (I have not tested the ECS/AGA 0.1 version)

[midwan]

I tested the FPU version (and it worked), but I'll run another test on a different OS installation also, to check if it behaves differently.

[amyren1966]

I notice that your post "Fixed with e0cd52c" refers to AARCH64 Does it mean the fix is for 64bit version? In that case I might be on differrent version here, I dont think I am running 64 bit OS on my Pi4. BTW, my build is dated 23-01-2021,

[midwan]

Ah, perhaps that was it. I tested the 64-bit only, as the JIT fix was related to aarch64 only and I wanted to see what other JIT-related issues it may have fixed. I'll run another test on 32-bit to see, if it's still an issue there then I'll report it back to TomB. :)

[midwan]

I can confirm this is happening under 32-bit JIT at least.

Interesting fact: RNOpdf requires the codesets.library which needed to be downloaded from Aminet. I wonder if the error comes from that library, not the application itself.

[midwan]

Tested it again on 64-bit JIT also:

• On WB3.9, it works fine
• On 3.1.4, it shows a software failure message (not the stack overflow error that we get on 32-bit)

So this seems to be specifically happening on 3.1.4, from what I can tell. Not sure why, at this point.

[midwan]

Under 3.1.4, it also throws a software failure for me even without JIT, so this part is not related to JIT.

[midwan]

Reported to TomB: https://github.com/PandTomB/uae4arm/issues/11

[amyren1966]

codesets.library is a requirement for all Hollywood programs. It is listed as one of the requirements for the Hollywood Player. Hollywood is a scripted language, and all executables made with Hollywood are basicly the Hollywood Player program packed together with the script and other needed files like sound samples, images etc.

[amyren1966]

What 64 bit Os distro are you using for Rpi4?

[midwan]

Manjaro: https://manjaro.org/download/#raspberry-pi-4

[amyren1966]

Thanks. Are there any benfits with 64 bit over 32 bit, apart from the JIT fix for 64 bit. My Rpi4 is the 4GB version.

[midwan]

@amyren1966 Amiberry runs much faster under 64-bit, mostly due to a faster JIT implementation there. Also, with Manjaro you get the latest versions of drivers and libraries directly (it's a rolling distro), so you benefit from any bugfixes there much sooner than in RPI OS. :)

[amyren1966]

Testing Manjaro (KDE Plasma) now. I'm getting this error when trying to compile amiberry-dev g++: error: unrecognized command-line option ‘-mfpu=neon-fp-armv8’

[midwan]

That's because you tried compiling the 32-bit target. Try with PLATFORM=pi64

[amyren1966]

Yes that was it. I was using the dispmanx instructions.

I can now confirm RNOPdf FPU version is working. Unfortunately the Hollywood games have the same issues as earlier on 64 bit as well.

I found a minor issue with the beta version, when setting fullscreen to yes in amiberry.conf it will still start up in windowed mode. When launching a uae config that is set to fullscreen, the GUI will show in fullscreen (800x600) when pressing F12. But then the startmenu bar will also show on this screen, making the bottom button row almost hidden. Amiberry 3.3 will open as fullscreen when launching the GUI, and the startmenu will not be shown when returning to GUI with F12. (actually it did pop up the startmenu once, but I wasnt able to reproduce it).

[amyren1966]

In case anyone else have the issue that the taskbar is covering the buttons in the amiberry GUI when in fullscreen. I just found a workaround by setting the KDE taskbar to Autohide and the problem is solved.

[leavreality]

I have the similar issue with hollywood. I made Amilion a very basic program for Amikit XE, that adds a few Rabbit hole features, it complains about "p_runevlist", but when I run in WinUAE the bug never happens. plus it fine when JIT is turned off, but then it runs really slowly.