Betatesting SoftIEEE FPU emulator

[PeterK]

Originally Posted by Thomas Richter

No, the 68881 and 68882 compute equally precise, but less precise than the software. That is, for elementary algebra, the two are equally precise, but for the additional functions SoftIEEE offers a higher precision.

Ok, that was a misunderstanding concerning the 67 bits and your 96 bits precision. You were talking about the mantissa only, which is, of course, responsible for the precision of the FPU. I just thought about 64 bit and 80 bit FPUs, the exponent included, and the 96 bit data format, which is used on PCs for long double.

[Flash951]

Thank you! I've replaced 060 lib (~160 KB) for MMU 060 lib (much smaller). TVPaint versions still crash, but give 'software failure' system message.

TVPaint 2.0 EGS record demos will now start, and partly work without error message. But will stop playing and not do the operations. Can exit without failure though.

Vampire guys got TVPaint 3.6 P96 to run with FEMU before they implemented FPU. Haven't got that to work with FEMU using 060LC though, only Vampire 2+.

[Thomas Richter]

You need to use the above revised version, not the first version.

[Flash951]

I did!

[Thomas Richter]

Well, as usual, please kindly run MuForce with the DISPC option, and kindly provide the output.

Here is another fix - this fixes a register trash affecting conversions to integer - thank you.

[Thomas Richter]

Another day, another update, sorry folks. However, I finally found a way how to test this on the real stuff. Friends from a1k kindly sponsored an A1200 a while ago, and iComp also provided an ACA1211lc, back then for testing the card.resource. Now, a quick swap of the accelerator later, I could finally run this version of SoftIEEE, and at least, it is now good enough to run my Deluxe Mandelbrot program. Slow, of course, but it works.

Chances are improving that the thing works correctly. This version runs AIBB correctly on the above 68020 based system. The defects so far are interestingly not related to numerics, but to register trashes and register assignments in the actual opcode interpreter (the SoftIEEE part) and not so much in the numerics (the softieee.library). The ATAN code trashed one register, and fmove to data register was broken.

[Flash951]

Still software failure for TVPaint 3.0 EGS and TVP jr. Will check with MUForce.

[Thomas Richter]

A new day, a new luck. There was an interesting defect in frestore(). For the 68040 and the 68030 (or rather the 68881/882), the frestore needs to read first the first long word of the saved data because this word contains the size of the frame. Unfortunately, when then reading the final frame, it used the wrong ea and might have trashed some registers.

[klx300r]

@ThoR

This is a great idea nowadays with the price of full 060’s and looking forward to seeing it progress!

[Flash951]

Great progress:
TVPaint 3.6 for P96 works!
TVPaint 2.0 EGS demos works!

TVPaint 3.0 EGS still fails:

[Thomas Richter]

Thanks, that's very valuable information. An interesting opcode they seem to use, let's see what I can do about it.

[Thomas Richter]

Yes, the problem was fmovems of control or FPU registers with empty register lists, i.e. essentially an fnop by other means. There was also a very minor issue that frestore on the 68060 did not use the correct function codes when the addressing mode was PC-relative. This needs to use a program-space function code, not a data-space function code.

There is nothing else today.

[a/b]

On fmovem control with an empty reg list being a fnop...
I just went through the docs (68k prg ref manual) and couldn't find it, but I 100% remember, and I'm 100% sure that if no control register is specified (all 3 bits are 0) it defaults to fpiar (so it's not "equivalent" to fnop). Manual states (5-93) that at least one reg must be specified, but, again, I can't find it now where I read about the "default" if nothing is selected. Once upon a time (~10 years ago) when I was working on my disassembler that's how I've implemented it (and pretty sure tested on a real 040).
Just did a quick test in winuae with a proper instruction (fmove(m) fpiar,(a0) = $f210, $a400) and modified opcode ($f210, $a000 nothing selected) and the result was identical.
Unless you meant you initially implemented it diffrenly and now it's ok, not really clear...

[Marce]

I was trying to run the program simple mail version 0.29 on winuae in a config without fpu
result: guru and crash

can anyone confirm that simple mail works with softieee in a real Amiga?

[Thomas Richter]

It *cannot* work with WinUAE at this point, so please do not test with it. As explained above, the current version of WinUAE has a defect that trashes one register upon entry into the exception handler.

[Toni Wilen]

Did no one read what I replied few days ago? That bug only affects 68060. (also not mentioning used config means: not enough information. It is also usually good idea to test few different configs, including enabled FPU, to confirm it is even FPU related problem!)

[Thomas Richter]

Originally Posted by a/b

On fmovem control with an empty reg list being a fnop...
Unless you meant you initially implemented it diffrenly and now it's ok, not really clear...

It was implemented as creating an invalid opcode (line F trap engaged), it is now implemented as a "nop". However, the faulting instruction at this point is a move multiple data registers, not move multiple control registers.

[a/b]

Well, what I'm trying to say it's not a "nop". It actually reads/writes fpiar if nothing is selected.
Checking winuae sources... fpp.cpp, line 3358:

				/* FMOVE(M) EA,Control Register(s) */
...
				// No control register bits set: FPIAR
				if (!(extra & (0x1000 | 0x0800 | 0x0400))) {
					extra |= 0x0400;
				}

Lines up with my recollection of how it works.
Did a test with softieee.library: $f210, $a000 (fmovem <no_ctrl_regs>,(a0) ) doesn't write to memory at all, and without the library (fpu present) fpiar is written.

edit: Made me anxious, pulled my A4000 out and tested it on real hardware: $f210, $a000 writes the fpiar to memory (exactly the same as $f210, $a400).

[Thomas Richter]

Thank you (though that is part of the emulator, not part of the numerical core in the library, i.e. SoftIEEE, not the softieee.library).

The interesting question rather is: What happens for the "move multiple data registers" instruction. Does that also read a register if the register list is empty.

[Toni Wilen]

Originally Posted by Thomas Richter

The interesting question rather is: What happens for the "move multiple data registers" instruction. Does that also read a register if the register list is empty.

FMOVEM <registers> with no registers selected does nothing.
FMOVEM <control registers> always moves at least one register (FPIAR if nothing selected).

(FMOVEM <registers> has some CPU specific differences when using invalid static/dynamic predecrement/postincrement mode bit combinations but afaik no programs do that)