Work on the Minimig core?

[slingshot]

Great, it's simple and works. Then finally MULs are fully working.

Uploaded the patch for minimig:
https://github.com/mist-devel/minimig-m ... 8b31a83284

[slingshot]

Here's the latest run of the cputester (I've removed unimplemented instructions). There are a variety of issues, like what's stored in MOVEM + predecremented address (which is data, too) and Trace flags in SR. DIV and PACK probably ALU related. And some others, where I have no idea.

[MasterOfGizmo]

Excellent. I'd like to run Nexus7 in this. But it seems i am too stupid. It just quits when i try to leave the intro screen ...

Anyway. Yes, this list isn't trivial to interpret. Maybe someone here would like to summarize this into code snippets that show the problem. Something like http://atari-forum.com/viewtopic.php?f= ... 25#p383381 is great!

[slingshot]

Excellent. I'd like to run Nexus7 in this. But it seems i am too stupid. It just quits when i try to leave the intro screen ...

Anyway. Yes, this list isn't trivial to interpret. Maybe someone here would like to summarize this into code snippets that show the problem. Something like http://atari-forum.com/viewtopic.php?f= ... 25#p383381 is great!

I think I could decrypt the DIV errors:
DIVS.W:
divs.w d1,d0
d1 = 0
d0= 0x10
Exception ID: expected 5 but got no exception.

So it should throw an exception because of the division by zero, but it didn't (happens with DIVU, too).

DIVL.L:
divul.l d0,d6:d0
d0 = 0x10
d6 = 7fff7fff
d0/d6=0, but got 7fff7fff in D6.
Also A6 is modified, so probably the register file is wrongly addressed (MSB should be always 0).

The MOVEM.L problem:
movem.l d2/d7/a0-a1/a3/a6,-(a1)
d2=ffffffff
d7=aaaaaaaa
a0=00000000
a1=00000080
.
.
.
at the end it should store the values like this (start address = 0x7c, this is A1 pre-decremented)
7c <= A6
78 <= A3
74 <= A1 - should store 7c (the first pre-decrement), but stored 80 (before pre-decrement)
70
.
.

[slingshot]

Excellent. I'd like to run Nexus7 in this. But it seems i am too stupid. It just quits when i try to leave the intro screen ...

I think it should continue on its own.
Found this: https://github.com/rkrajnc/minimig-mist/issues/79

[MasterOfGizmo]

I think it should continue on its own.
Found this: https://github.com/rkrajnc/minimig-mist/issues/79

But it doesn't ... it simply crashes after 30 mins ...

[MasterOfGizmo]

74 <= A1 - should store 7c (the first pre-decrement), but stored 80 (before pre-decrement)

That one will be tricky ...

[slingshot]

I think it should continue on its own.
Found this: https://github.com/rkrajnc/minimig-mist/issues/79

But it doesn't ... it simply crashes after 30 mins ...

Seems it needs Turbo: Both option

[MasterOfGizmo]

Seems it needs Turbo: Both option

Yeah, but that also doesn't help. Whatever. I don't need a working board to debug the CPU so i'll ignore that by now.

[MasterOfGizmo]

I think I could decrypt the DIV errors:
DIVS.W:
divs.w d1,d0
d1 = 0
d0= 0x10
Exception ID: expected 5 but got no exception.

Hmm. I see the exception happen. I'd be very surprised if such a fundamental error still exists.

[slingshot]

I think I could decrypt the DIV errors:
DIVS.W:
divs.w d1,d0
d1 = 0
d0= 0x10
Exception ID: expected 5 but got no exception.

Hmm. I see the exception happen. I'd be very surprised if such a fundamental error still exists.

I have no idea how the tester checks for it. Maybe similar issue to the Trace flags, just there the opposite else happens: trace exception thrown, but not expected (but I would expect it, as the trace flags are just set).

[slingshot]

Seems I read an older log of DIVL.L:

divul.l d0,d6:d0
d0 = 0x10
d6 = 7fff7fff
SR: expected 0400 -> 0402 but got 040a
Only SR N bit is set wrongly.
Looks like an undocumented behavior: N flag during DIV overflow. According to http://68k.hax.com/DIVU " Undefined if overflow or divide by zero occurs. "

Upd.: some expected behavior of the N flag during overflow
00000010 7FFF7FFF : 10 => expected N=0
FFFF0000 AAAAAAAA : 10 => expected N=1
Maybe the sign of the dividend (but it doesn't map to op1int(15), I've already lost what register contains this at the end of the operation).

The other problem is fixed by some previous commit already.
The exception issue doesn't change.

[robinsonb5]

But the real odd thing is the comment '''--???'''. I wonder who put it there. It's been there for at least 7 years and it seems someone tried to fix the same problem. I wonder why he kept that line.

The "???" may well have been me, back when I first starting tinkering with the TC64 version of the Minimig core - I suspect I left it as a note to myself to revisit that code and try and figure out what was going on. I wasn't attempting to fix bugs in MUL, though - I was attempting (and failing) to replace the ALU multiplier with a hardware multiplier in the hope of bringing down the logic usage a bit.

[slingshot]

Seems I read an older log of DIVL.L:

Hovewer this is a real issue:
d0=0x10
d1=0
d5=80008080

divsl.l d0,d1:d5
d5 - negative, d0 - positive, result -> negative
expected SR -> 0408 (N=1), result -> 0400 (N=0)

[MasterOfGizmo]

Hovewer this is a real issue:
d0=0x10
d1=0
d5=80008080

divsl.l d0,d1:d5
d5 - negative, d0 - positive, result -> negative
expected SR -> 0408 (N=1), result -> 0400 (N=0)

try changing
https://github.com/mist-devel/minimig-m ... U.vhd#L766
to

Code: Select all

  Flags(3 downto 0) <= set_flags(3) & flag_z(1) & "00";

I would actually expect this to have a negative impact on other div variants but i haven't found one

[slingshot]

try changing
https://github.com/mist-devel/minimig-m ... U.vhd#L766
to

Code: Select all

  Flags(3 downto 0) <= set_flags(3) & flag_z(1) & "00";

I would actually expect this to have a negative impact on other div variants but i haven't found one

I can try this later. I guess two lines above is the undocumented behavior, maybe the same works there, too.

[slingshot]

Code: Select all

  Flags(3 downto 0) <= set_flags(3) & flag_z(1) & "00";

I would actually expect this to have a negative impact on other div variants but i haven't found one

This one satisfy the undocumented N flag behavior, too (but I wonder if it's correct in 68000 mode - checked in @ijor's FX68K, I think it always sets to '1', as the code does now).

Code: Select all

			if V_Flag = '1' then
			  Flags(3 downto 0) <= not (signedOP xor set_flags(3)) & "010";
			else
			  Flags(3 downto 0) <= set_flags(3) & flag_z(1) & "00";
			end if;

And now it hits the no exception issue.

[MasterOfGizmo]

And now it hits the no exception issue.

I wonder what that is. Maybe they have tracing enabled all the time and there's a collision between the trace exception and the div by zero one? Dunno ...

[slingshot]

And now it hits the no exception issue.

I wonder what that is. Maybe they have tracing enabled all the time and there's a collision between the trace exception and the div by zero one? Dunno ...

I found the code which writes the message:
https://github.com/tonioni/WinUAE/blob/ ... in.c#L1280
Receiving an exception 4 (illegal instruction) means no exception here?

Or maybe it correlates with the failures in RTE? (but as I see, it's just a problem with expecting a Format Error exception, maybe an unhandled error in an unusual exception frame - edit: Format Error is unimplemented, that's why RTE test fails).

[slingshot]

And now it hits the no exception issue.

I wonder what that is. Maybe they have tracing enabled all the time and there's a collision between the trace exception and the div by zero one? Dunno ...

I think I found out what happens: right after the div instruction, there's an illegal opcode. And the illegal exception overrides the divide by zero, however it shouldn't (set_z_error is set, but z_error not, however trap_illegal kicking in).

[MasterOfGizmo]

I think I found out what happens: right after the div instruction, there's an illegal opcode.

When I run this code:

Code: Select all

	divs.w  #0,d0
	illegal		

First the division by zero trap is executed and then the illegal instruction trap just as i would expect.

One thing i have noticed is that if i rte from the illegal trap then the illegal instruction is executed again (and again ....). Is this correct behaviour? Or should the execution continue after the illegal instruction?

What I've also noticed: There's no address error at all in tg68k, not even in 68k mode. It just accesses odd addresses. But can address errors ever happen on a 68020?

[slingshot]

I think I found out what happens: right after the div instruction, there's an illegal opcode.

When I run this code:

Code: Select all

	divs.w  #0,d0
	illegal		

First the division by zero trap is executed and then the illegal instruction trap just as i would expect.

Probably the case I found wasn't related to the failure the test caught. Don't know if it's possible during the processing of the DIV that set_z_error goes to 1, then it's discarded. Need to record much more internal signals to determine.

One thing i have noticed is that if i rte from the illegal trap then the illegal instruction is executed again (and again ....). Is this correct behaviour? Or should the execution continue after the illegal instruction?

I think it's OK, from the 68020 manual:

Code: Select all

The illegal or unimplemented instruction vector offset, current PC, and copy of theSR are saved on the supervisor stack, with the saved value of the PC being the addressof the illegal or unimplemented instruction. Instruction execution resumes at the addresscontained in the exception vector. It is the responsibility of the handling routine to adjustthe stacked PC if the instruction is emulated in software or is to be skipped on return fromthe handler.

What I've also noticed: There's no address error at all in tg68k, not even in 68k mode. It just accesses odd addresses. But can address errors ever happen on a 68020?

Code: Select all

An address error exception occurs when the processor attempts to prefetch an instructionfrom an odd address.

68020 has a 32 bit data bus, probably that's why only the prefetch causes an address execption (it should fit into one memory access cycle), otherwise odd/even address distinction wouldn't be useful. Interesting if a longword fetch could be split into two access cycles.

But at the end, still no idea what causes the test failures. Maybe if MikeJ releases M68K, would worth to check it also. The latest ALU related fixes would be easy to port, if he cleaned up exception handling/stack frames/whatever.

[MasterOfGizmo]

So the remaining CPU issues are pretty exotic and I wouldn't expect them to have an impact on real life applications. Or is there anything you think is worth fixing now? And yes, combining our work with Mikes work is likely a good idea. Maybe he's listening and is incorporating our findings already into his version.

Or is there anything that you think is worth fixing?

[slingshot]

Or is there anything that you think is worth fixing?

I think if the CPU can do the math correctly, then it's good enough Maybe PACK can be investigated, that probably also ALU related, but don't affect real-world apps, too.

[slingshot]

Here's a build with the MUL and DIV fixes. Works very well for me.