68040 MMU use when JIT on

Yoji · 15 June 2021, 18:21

Anyone able to explain what going on here? I was messing with my WinUAE emulated 3.1.4.1 and 3.2 systems and noticed that in sysinfo 4.4 it was showing the MMU was working in my 3.1.4.1 environment - which is strange as WinUAE says MMU is incompatible with JIT .. so is off and greyed out, yet showing as in use in Sysinfo? So I checked my 3.2 environment and thats working as expected.. i.e. sysinfo show MMU not in use and in WinUAE it showing greyed out and not selected.
So I wondered if it the 68040.library was different and somehow causing MMU to show in use the the 3.1.4.1 env..
Sure enough.. it an older lib 37.3..... and the one in 3.2 is ver 46.3... so I thought I would upgrade the 68040 lib... since it supposed to be generic..but when I put it in my 3.1.4.1 env I got a soft/recoverable Guru telling me I needed a 68040 lib? which was a surprise...
So anyone know why sysinfo showing the MMU in use when it turned off in WinUAE?
And anyone know why the 46.3 generic 68040 lib (that comes with 3.2) blows up a 3.1.4.1 install?
Thanks for any insight

Yoji · 15 June 2021, 18:28

OK.. quick update.. looks like sysinfo is wrong... although it says it on in sysinfo, when I use the shell "Cpu mmutype" command it comes back with "none"... so I guess we should trust the OS.
But still interested if the newer 68040 lib issue is a surprise?

coldacid · 15 June 2021, 18:46

Yeah, you'd be better off checking those kinds of details out with Scout.

Toni Wilen · 15 June 2021, 18:56

MMU is faked. All registers and instructions work but they do nothing.

You selected CPU model that is supposed to have MMU -> MMU gets faked if it can't be emulated fully. It also makes it more compatible with old MMU library versions that don't like no-MMU CPU models. MMU setup isn't really needed under emulation anyway in normal use (excluding debugging where it can be very useful).

Later MMU library version probably checks that MMU address translation works.

Yoji · 15 June 2021, 20:34

Thanks,

Yes, I appreciate its all faked.. CPU/FPU/MMU/Chip sets.. everything.
My understanding was that to emulate the MMU slows everything down in a modern emulation environment - which is why it is forcefully set off when you set JIT.
But it is strange (to a noob like me) that the newer libs would cause problems.
TBH I cant recall where I got the old 37.3 libs from, perhaps from somewhere when building my real A4000/40 machine build... but I did not expect a 3.2 generic 68040 lib to cause problems with what is in effect a very basic 3.1.4.1 OS build..
If as you say, it may check to see if MMU address translation works.. you would not expect it to blow up if it does not find it? after all... some 68040 genuine chips dont have the MMU? (EC versions?)
Cheers

Yoji · 19 June 2021, 17:01

OK.. someone else said the lib with blow up with JIT enabled.. which sounded strange... but I thought I would do some more test
I think I closer to understanding now...
When 3.1.4.1 and JIT and 68040.library 37.3 the CPU command reports as "68040 68882" (with some cache info)....
When 3.2 and JIT and 68040.library 46.3 the CPU command reports as "68040 68882" (with some cache info)
When 3.1.4.1 and JIT and 68040.library 46.3 the CPU command reports as "68040 68040/060-FPU" (with some cache info)
Disabling JIT and then having MMU on or off, makes no difference in that last scenario.. with the 46.3 library.. the 3.1.4.1 environment always blows up.
So the 46.3 lib reports CPU differently depending on workbench version number.. and thats what is triggering the issue.
Slightly strange that it does report it as a 68040 present in all test scenarios.. but the scripting does not like the response, as it reports a "CPU failed returncode 30"
I dont know the details of if it differences in the CPU command between 3.1.4 and 3.2 or library.. or interaction between both.

Yoji · 19 June 2021, 19:33

Yet another update... on advice ... looks like I was wrong to think I could just change the 68040.library. going through the official "install" process included with the mmulibs.lha pack, it worked its magic and the 3.1.4.1 install works fine and is using the 46.3 68040.library.
If I run with JIT on - it works (knowing no MMU is avail) and if I turn off JIT and turn on MMU, it identified mmu avail and uses it just fine.
So looks like I need RTFM (

) to understand whats going on
but after install.. the CPU command is back to reporting
"68040 68882 No Fastrom" (and some cache info)

15 June 2021, 18:21	#1
Yoji Registered User Join Date: May 2015 Location: newcastle-under-lyme Posts: 87	68040 MMU use when JIT on Anyone able to explain what going on here? I was messing with my WinUAE emulated 3.1.4.1 and 3.2 systems and noticed that in sysinfo 4.4 it was showing the MMU was working in my 3.1.4.1 environment - which is strange as WinUAE says MMU is incompatible with JIT .. so is off and greyed out, yet showing as in use in Sysinfo? So I checked my 3.2 environment and thats working as expected.. i.e. sysinfo show MMU not in use and in WinUAE it showing greyed out and not selected. So I wondered if it the 68040.library was different and somehow causing MMU to show in use the the 3.1.4.1 env.. Sure enough.. it an older lib 37.3..... and the one in 3.2 is ver 46.3... so I thought I would upgrade the 68040 lib... since it supposed to be generic..but when I put it in my 3.1.4.1 env I got a soft/recoverable Guru telling me I needed a 68040 lib? which was a surprise... So anyone know why sysinfo showing the MMU in use when it turned off in WinUAE? And anyone know why the 46.3 generic 68040 lib (that comes with 3.2) blows up a 3.1.4.1 install? Thanks for any insight

19 June 2021, 19:33	#7
Yoji Registered User Join Date: May 2015 Location: newcastle-under-lyme Posts: 87	Yet another update... on advice ... looks like I was wrong to think I could just change the 68040.library. going through the official "install" process included with the mmulibs.lha pack, it worked its magic and the 3.1.4.1 install works fine and is using the 46.3 68040.library. If I run with JIT on - it works (knowing no MMU is avail) and if I turn off JIT and turn on MMU, it identified mmu avail and uses it just fine. So looks like I need RTFM () to understand whats going on but after install.. the CPU command is back to reporting "68040 68882 No Fastrom" (and some cache info)

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
68030, 68040 and 68060 MMU support (really!)	Toni Wilen	support.WinUAE	262	19 February 2019 12:36
JIT mode for 68040 available?	pixelsmack	support.FS-UAE	4	17 July 2014 00:00
WinUAE crashes when switching from MMU to JIT	jotd	support.WinUAE	1	19 November 2010 21:34
68040 MMU jsr/bsr	Toni Wilen	Coders. General	5	28 April 2010 20:57
MMU/JIT toggle on native mode	jotd	request.UAE Wishlist	3	18 September 2009 20:36

15 June 2021, 18:28	#2
Yoji Registered User Join Date: May 2015 Location: newcastle-under-lyme Posts: 87	OK.. quick update.. looks like sysinfo is wrong... although it says it on in sysinfo, when I use the shell "Cpu mmutype" command it comes back with "none"... so I guess we should trust the OS. But still interested if the newer 68040 lib issue is a surprise?

15 June 2021, 18:46	#3
coldacid WinUAE 4000/40, V4SA Join Date: Apr 2020 Location: East of Oshawa Posts: 538	Yeah, you'd be better off checking those kinds of details out with Scout.

15 June 2021, 18:56	#4
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	MMU is faked. All registers and instructions work but they do nothing. You selected CPU model that is supposed to have MMU -> MMU gets faked if it can't be emulated fully. It also makes it more compatible with old MMU library versions that don't like no-MMU CPU models. MMU setup isn't really needed under emulation anyway in normal use (excluding debugging where it can be very useful). Later MMU library version probably checks that MMU address translation works.

15 June 2021, 20:34	#5
Yoji Registered User Join Date: May 2015 Location: newcastle-under-lyme Posts: 87	Thanks, Yes, I appreciate its all faked.. CPU/FPU/MMU/Chip sets.. everything. My understanding was that to emulate the MMU slows everything down in a modern emulation environment - which is why it is forcefully set off when you set JIT. But it is strange (to a noob like me) that the newer libs would cause problems. TBH I cant recall where I got the old 37.3 libs from, perhaps from somewhere when building my real A4000/40 machine build... but I did not expect a 3.2 generic 68040 lib to cause problems with what is in effect a very basic 3.1.4.1 OS build.. If as you say, it may check to see if MMU address translation works.. you would not expect it to blow up if it does not find it? after all... some 68040 genuine chips dont have the MMU? (EC versions?) Cheers

19 June 2021, 17:01	#6
Yoji Registered User Join Date: May 2015 Location: newcastle-under-lyme Posts: 87	OK.. someone else said the lib with blow up with JIT enabled.. which sounded strange... but I thought I would do some more test I think I closer to understanding now... When 3.1.4.1 and JIT and 68040.library 37.3 the CPU command reports as "68040 68882" (with some cache info).... When 3.2 and JIT and 68040.library 46.3 the CPU command reports as "68040 68882" (with some cache info) When 3.1.4.1 and JIT and 68040.library 46.3 the CPU command reports as "68040 68040/060-FPU" (with some cache info) Disabling JIT and then having MMU on or off, makes no difference in that last scenario.. with the 46.3 library.. the 3.1.4.1 environment always blows up. So the 46.3 lib reports CPU differently depending on workbench version number.. and thats what is triggering the issue. Slightly strange that it does report it as a 68040 present in all test scenarios.. but the scripting does not like the response, as it reports a "CPU failed returncode 30" I dont know the details of if it differences in the CPU command between 3.1.4 and 3.2 or library.. or interaction between both.

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