FS-UAE / WinUAE x86-64 JIT Compiler

[jbl007]

Originally Posted by FrodeSolheim

HD-REC should now start without crashing the emulator

Works now. I should have sent you the test-hdf earlier, and not making stupid debug attempts. Next time I'll do.
It also looks like some of your changes fixed the precision problem/difference I mentioned earlier. No differences in the wave forms visible anymore. But I'm curious... Was it the change that caused the crash in the 64bit version?

Anyway... Finding more non-working example applications which use rarely used FPU functions/features sounds like finding the needle in the haystack. But I don't give up!

Originally Posted by Romanujan

For Linux users there is another reason - slowly getting rid of the legacy components from the OS. 32-bit x86 software should have died out 5 years ago...

Exactly! Many distros are 64 bit only. So it's super cool we can have JIT for 64 bit OS.

[Dic_Ray]

@Frode You are such a genius. This is your ultimately entry in the hall of fame. I'm looking forward to get your new development build.

[bernd roesch]

Originally Posted by FrodeSolheim

@jbl007 Thank you, it worked fine (= it crashed )

You will not be able to get a stack trace in the debugger, because the crashes almost always happens in JIT-generated code, which is just one large 8 MB (typically) segment with generated code (no regular C functions here). In this particular crash, it was even worse, because when the stack is corrupted, more stupid things starts to happen, and the crash is often unrelated to the actual stack corruption.

great that you find. the 68k output with winuaeenforcer is usefull in JIT too, to find the block of 68k code that cause crash. remember what i write here before, that the 1. loop is always execute with interpreter. also should know, that the JIT at the end of every block update 68k PC

So if you get a error in winuaeenforcer(or you look in gdb what PC value is, when uae crash) this show the last block that is exectute from JIT . the real error is then later in the code. For example

68k code contain this

$1000 addq #1,d0
$1002 dbf d1,$980
$1006 wrong instruction
...............................
$1020 bne $1010

Then the 1. JIT block range from $980 upto $1006-1
second JIT block range from $1006 upto $1010-1
third JIT block range from $1010 upto $1020-1

the reason wy JIT code generation always do 1 loop with interpreter is, because it can not know that $1010 should be start of a block. JIT only notice because of backjump at $1020 (bne $1010) that $1010 need start of block. so there is always 1 loop need that do with interpreter


now when the JIT code reach $1006 it crashes and maybe winuaeenforcer do a output, because of wrong address.

But because the PC is not exact(because code is before execute with interpreter), you need look what is done before in this block or look at the next block. so you need only look at 68k code of JIT block1 and JIT block2.

If know this, then winuaeenforcer is very usefull and help find problems faster

[jbl007]

Cybercinematastic by Loonies
Crash at the end of the demo
log:

JIT: Fault address is 0x7c295bea at PC=0x423817ac
JIT: Can't handle access PC=0x423817ac!
JIT: Instruction bytes 67 45 8a a3 00 00 00 50 67 44

[FrodeSolheim]

Originally Posted by jbl007

But I'm curious... Was it the change that caused the crash in the 64bit version?

Accuracy must have been fixed by earlier fixes. The latest crash issue (FSINH) was more or less to guaranteed to crash every time (and therefore it cannot have caused accuracy problems )

Originally Posted by jbl007

JIT: Fault address is 0x7c295bea at PC=0x423817ac
JIT: Can't handle access PC=0x423817ac!
JIT: Instruction bytes 67 45 8a a3 00 00 00 50 67 44

Thank you, this is exactly what I need. I can actually tell from this output (with almost certainty) what the problem is. If we punch the instruction bytes into a disassembler we get:

67 45 8a a3 00 00 00    mov r12b,BYTE PTR [r11d+0x50000000]

i.e. move a byte to (the lower 8 bits of the x86-64) register r12 from memory location 0x50000000 + the 32-bit value in register r11(d). 0x50000000 is the start of the Amiga address space in FS-UAE virtual (native) memory.

FS-UAE crashes because there isn't anything at location 0x7c295bea. We can easily calculate the (Amiga) address the demo tries to access:

0x7c295bea - 0x50000000 = 0x2c295bea

So 0x2c295bea is the content of the r11d register and the demo tries to read one byte from (Amiga address) 2C295BEA. You can also verify with the "Memory map after autoconfig" in FS-UAE.log.txt that there isn't any memory bank at this address.

On a real hardware, nothing will crash (by itself) when the demo reads from non-existing memory. -And in FS-UAE, normally, this should be handled by the access fault handler. The problem (and the cause of the crash) is that the access handler does not understand this *specific* x86-64 instruction, and thus cannot figure out how to handle it.

The fix is to extend the instruction decoder in the access fault handler to understand mov instructions related to all the (new) x86-64 registers (It would have worked if JIT had chosen one of the original x86 registers instead of a "new" x86-64 register). I'll probably borrow some code from the ARAnyM project, as it looks like they have implemented a much more complete instruction decoder for x86-64

But with this knowledge, we can also speculate about a couple of workarounds (both should work) until I have fixed the instruction decoder:

1. Make sure valid memory is available in this location. For example, to make sure we have Zorro III memory from 0x10000000 to 0x30000000 (containing the location 0x2c295bea):

zorro-iii-memory = 512M
uae-z3mapping = uae

2. Use indirect memory access instead of direct

(Don't worry, I will not write an "essay" for every new discovered problem )

Anyway, thanks, this will be a good use for testing the new instruction decoder once I've implemented it!

[FrodeSolheim]

I ended up writing proper support for REX / x86-64 extended register usage myself (ARAnyM instruction decoder was a bit overkill), and I have pushed the code to github

(This fixes the "Cybercinematastic by Loonies" demo)

I expect to release 2.7.1dev tomorrow, unless some showstopper appears!

[jbl007]

Perhaps another showstopper:
https://files.scene.org/view/parties...o/ahonen_d.zip

JIT: Fault address is 0xdb0a5f84 at PC=0x40dd48c7
JIT: Can't handle access PC=0x40dd48c7!
JIT: Instruction bytes 67 45 8b 9a 00 00 00 50 41 0f

[FrodeSolheim]

@jbl007 looks like a similar problem (except write instead of read, and another address, and slightly different registers), probably fixed by the latest commit (?)

[jbl007]

Compiling... Please wait.

Edit:
It works! :-)

[FrodeSolheim]

FS-UAE 2.7.1dev is now available with x86-64 JIT updates, and 64-bit builds for Windows, OS X and SteamOS

I haven't had time to test the new (64-bit) packages any much, so there could be issues with these. Please report in the development series thread if you experience issues which has nothing to do with the x86-64 JIT compiler.

EDIT: I forgot to enable FPU JIT by default in FS-UAE 2.7.1dev. You are now encouraged to use uae_compfpu = 1 to test with the FPU JIT enabled. It something fails, please test without too and report your findings.

Originally Posted by jbl007

t works! :-)

Great

[Romanujan]

On 2.7.1dev I have found yet another 1024M related crash, this time certainly related to JIT (unfortunately, I don't have the environment to test it on a 32-bit build), and with much more complex configuration - config + logs in the attachment.

[FrodeSolheim]

Originally Posted by Romanujan

On 2.7.1dev I have found yet another 1024M related crash, this time certainly related to JIT (unfortunately, I don't have the environment to test it on a 32-bit build), and with much more complex configuration - config + logs in the attachment.

Thank your for the bug report! It looks similar to a known problem (from the WinUAE 3200b13 announcement):

Originally Posted by Toni Wilen

- Use "UAE" RAM allocation mode (not "Real") if you want max available Z3 RAM (up to 1.5G. Z3 RAM + RTG VRAM + 256M must be less than or equal to 2G. Anything more = crash.

I'll debug a little more to be sure, but it certainly has something do with memory allocations getting shuffled around due to the uaegfx board.

[FrodeSolheim]

The crash happens when there is no room for the RTG memory within the reserved memory region (and right now, the code handles this in a way which guarantees a crash...)

The problem is that you have allocated an 2 GB address space, and using the A4000/PPC model forces Z3 "real mapping", which leaves only 1 GB available for Zorro III devices. Since you are using up all that space for RAM, there is no room the the RTG card (and the aforementioned crash happens).

I'll think about how to best handle this (or perhaps Toni will), but for now, let's just call this a "feature" ;-)

(You can see that this is the same crash as Toni refers too, by replacing 256M with 1GB due to Z3 real mapping, and 1.5G Z3 RAM with 1.0G).

[Toni Wilen]

Originally Posted by FrodeSolheim

The crash happens when there is no room for the RTG memory within the reserved memory region (and right now, the code handles this in a way which guarantees a crash...)

The problem is that you have allocated an 2 GB address space, and using the A4000/PPC model forces Z3 "real mapping", which leaves only 1 GB available for Zorro III devices. Since you are using up all that space for RAM, there is no room the the RTG card (and the aforementioned crash happens).

I'll think about how to best handle this (or perhaps Toni will), but for now, let's just call this a "feature" ;-)

(You can see that this is the same crash as Toni refers too, by replacing 256M with 1GB due to Z3 real mapping, and 1.5G Z3 RAM with 1.0G).

I don't think it can be (nicely) solved because technically software is free to put the memory anywhere it wants, emulator can only assume normal Z3 allocation (including space wasting aligment rules) or try to force it to some other location ("UAE" mapping). At least it can't be solved until it is already too late

I would be happy with solution that removes the crash, even halting the emulation ("memory config is impossible, can't continue") would be fine.

[FrodeSolheim]

Originally Posted by Toni Wilen

I don't think it can be (nicely) solved because technically software is free to put the memory anywhere it wants, emulator can only assume normal Z3 allocation (including space wasting aligment rules) or try to force it to some other location ("UAE" mapping). At least it can't be solved until it is already too late

I would be happy with solution that removes the crash, even halting the emulation ("memory config is impossible, can't continue") would be fine.

I agree that just stopping the emulation with error message is an OK solution.

It isn't possible to allow this to work with JIT direct memory, but one possible solution (for this specific case at least) is to allocate RTG memory somewhere else (non-contiguous) when it does not fit into the contiguous memory region. jit_direct_compatible_memory is already false, so canbang will be set to false as well, which means that JIT memory access will look up address bank offsets from the memory bank structures (kind of semi-direct memory access) -and this does not require contiguous host memory.

(Of course, there could still be issues with Amiga-side software not dealing with > 0x80000000 pointers properly)

[Romanujan]

Originally Posted by FrodeSolheim

(Of course, there could still be issues with Amiga-side software not dealing with > 0x80000000 pointers properly)

If so, then I am not sure if it is a good idea to allow such a configuration - at least I prefer to have less memory available and a stable system.

[Toni Wilen]

It isn't possible to allow this to work with JIT direct memory, but one possible solution (for this specific case at least) is to allocate RTG memory somewhere else (non-contiguous) when it does not fit into the contiguous memory region.

Probably only working solution.

(Of course, there could still be issues with Amiga-side software not dealing with > 0x80000000 pointers properly)

That is not emulator's problem

Originally Posted by Romanujan

If so, then I am not sure if it is a good idea to allow such a configuration - at least I prefer to have less memory available and a stable system.

You can have exact same situation using real hardware. It must be possible to configure it in emulation too. For example if someone wants to debug what and how it goes wrong, much easier when using emulation.

[FrodeSolheim]

Several 64-bit JIT related fixes have been pushed to https://github.com/FrodeSolheim/fs-uae (Some of them only related to Windows).

Includes fix for crashes when using Blizzard CPU boards and JIT.

Windows 64-bit JIT bugs fixed include:
- Rounding errors in the JIT FPU.
- Crashes due to not presering RDI and RSI registers correctly for Windows x86-64.
- Crashes due to missing shadow stack space for register parameters on Windows x86-64.

Originally Posted by Toni Wilen

I would be happy with solution that removes the crash, even halting the emulation ("memory config is impossible, can't continue") would be fine.

Btw, I haven't done anything with this particular issue yet (and not really JIT-related either). Just mentioning it so people don't think it has been fixed.

[ceztko]

Originally Posted by FrodeSolheim

This isn't a "new JIT compiler" as such, it is a modification of the old one (including a big merge of JIT code from the ARAnyM project...).

Question: ARAnyM 1.0.0 changelog mentions that the JIT engine should work on ARM platform. Does this mean that FS-UAE can or could be compiled on ARM (read => Android) with full JIT working?

[FrodeSolheim]

Originally Posted by ceztko

Question: ARAnyM 1.0.0 changelog mentions that the JIT engine should work on ARM platform. Does this mean that FS-UAE can or could be compiled on ARM (read => Android) with full JIT working?

Yes and no. It means that is possible that an ARM+JIT version of FS-UAE will exist at one point, but it is not just a matter of building it. UAE contains additional JIT code which does not exist in ARAnyM, so it requires:
- Additional work to complete ARM JIT for UAE.
- Additional work to adapt FS-UAE to Android.

So the answer is yes, provided that a skilled developer can spend a lot of time on it