English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.FS-UAE

 
 
Thread Tools
Old 25 September 2015, 02:40   #41
jbl007
Registered User
 
Join Date: Mar 2013
Location: Leipzig/Germany
Posts: 320
Quote:
Originally Posted by FrodeSolheim View Post
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!

Quote:
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.
jbl007 is offline  
AdSense AdSense  
Old 25 September 2015, 10:58   #42
Dic_Ray
Registered User
 
Join Date: Jul 2004
Location: Germany
Posts: 94
@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.
Dic_Ray is offline  
Old 25 September 2015, 11:06   #43
bernd roesch
Registered User
 
Join Date: Apr 2012
Location: germany
Posts: 72
Quote:
Originally Posted by FrodeSolheim View Post
@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

Last edited by bernd roesch; 25 September 2015 at 11:17.
bernd roesch is offline  
Old 25 September 2015, 14:37   #44
jbl007
Registered User
 
Join Date: Mar 2013
Location: Leipzig/Germany
Posts: 320
Cybercinematastic by Loonies
Crash at the end of the demo
log:
Code:
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
jbl007 is offline  
Old 25 September 2015, 17:49   #45
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 36
Posts: 3,314
Quote:
Originally Posted by jbl007 View Post
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 )

Quote:
Originally Posted by jbl007 View Post
Code:
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:
Code:
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:
Code:
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):
Code:
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!

Last edited by FrodeSolheim; 26 September 2015 at 15:16.
FrodeSolheim is offline  
Old 26 September 2015, 02:38   #46
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 36
Posts: 3,314
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!

Last edited by FrodeSolheim; 26 September 2015 at 02:59.
FrodeSolheim is offline  
Old 26 September 2015, 02:52   #47
jbl007
Registered User
 
Join Date: Mar 2013
Location: Leipzig/Germany
Posts: 320
Perhaps another showstopper:
https://files.scene.org/view/parties...o/ahonen_d.zip
Code:
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
jbl007 is offline  
Old 26 September 2015, 02:53   #48
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 36
Posts: 3,314
@jbl007 looks like a similar problem (except write instead of read, and another address, and slightly different registers), probably fixed by the latest commit (?)

Last edited by FrodeSolheim; 26 September 2015 at 02:59.
FrodeSolheim is offline  
Old 26 September 2015, 02:54   #49
jbl007
Registered User
 
Join Date: Mar 2013
Location: Leipzig/Germany
Posts: 320
Compiling... Please wait.

Edit:
It works! :-)

Last edited by jbl007; 26 September 2015 at 03:02. Reason: because it works...
jbl007 is offline  
Old 26 September 2015, 14:57   #50
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 36
Posts: 3,314
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.

Quote:
Originally Posted by jbl007 View Post
t works! :-)
Great

Last edited by FrodeSolheim; 26 September 2015 at 15:07.
FrodeSolheim is offline  
Old 26 September 2015, 23:22   #51
Romanujan
Registered User
 
Join Date: Dec 2007
Location: Szczecin/Poland
Posts: 144
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.
Attached Files
File Type: 7z Crash.tar.7z (11.5 KB, 116 views)
Romanujan is offline  
Old 26 September 2015, 23:49   #52
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 36
Posts: 3,314
Quote:
Originally Posted by Romanujan View Post
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):

Quote:
Originally Posted by Toni Wilen View Post
- 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 is offline  
Old 27 September 2015, 00:59   #53
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 36
Posts: 3,314
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).
FrodeSolheim is offline  
Old 27 September 2015, 13:44   #54
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 41
Posts: 18,492
Quote:
Originally Posted by FrodeSolheim View Post
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.
Toni Wilen is offline  
Old 27 September 2015, 14:21   #55
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 36
Posts: 3,314
Quote:
Originally Posted by Toni Wilen View Post
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)

Last edited by FrodeSolheim; 27 September 2015 at 15:15.
FrodeSolheim is offline  
Old 27 September 2015, 15:49   #56
Romanujan
Registered User
 
Join Date: Dec 2007
Location: Szczecin/Poland
Posts: 144
Quote:
Originally Posted by FrodeSolheim View Post
(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.
Romanujan is offline  
Old 27 September 2015, 15:55   #57
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 41
Posts: 18,492
Quote:
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.

Quote:
(Of course, there could still be issues with Amiga-side software not dealing with > 0x80000000 pointers properly)
That is not emulator's problem

Quote:
Originally Posted by Romanujan View Post
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.
Toni Wilen is offline  
Old 13 October 2015, 01:32   #58
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 36
Posts: 3,314
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.

Quote:
Originally Posted by Toni Wilen View Post
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.
FrodeSolheim is offline  
Old 13 October 2015, 13:30   #59
ceztko
Registered User
 
Join Date: Aug 2006
Location: Italy
Posts: 76
Quote:
Originally Posted by FrodeSolheim View Post
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?
ceztko is offline  
Old 14 October 2015, 00:36   #60
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 36
Posts: 3,314
Quote:
Originally Posted by ceztko View Post
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
FrodeSolheim is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
It seem the JIT direct mode is not work in fs-uae. direct mode is important bernd roesch support.FS-UAE 27 20 September 2015 22:44
E-UAE PowerPC JIT v1.0.0 is here! Puni/Void Amiga scene 0 02 January 2015 20:51
Question about the possibility of JIT in FS-UAE under Windows SaphirJD support.FS-UAE 4 20 December 2013 23:08
FS-UAE - Why it have no JIT? nexusle support.FS-UAE 19 13 May 2012 14:39
JIT on E-UAE PPC? _ThEcRoW support.OtherUAE 8 07 May 2011 00:55

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 01:34.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.26598 seconds with 13 queries