FPU Compatible Software

[thorsten.otto]

Yes, that's correct, the startup code calls _fpuinit in the library to check for presence of a memory-mapped FPU. If you have removed that call from your own startup code, then its your fault (there might however be reasons for it, some emulators may not like the bus-error that will result most of the time).

And yes, i would also expect that memory-mapped FPU to be faster than pure software calculation. Otherwise it would not make much sense to develop such a device, or to support it in libraries. But it will still be much slower than a "real" FPU.

As to applications: Texel might be good candidate for it.

[pixelpusher]

Yes, that's correct, the startup code calls _fpuinit in the library to check for presence of a memory-mapped FPU. If you have removed that call from your own startup code, then its your fault (there might however be reasons for it, some emulators may not like the bus-error that will result most of the time).

And yes, i would also expect that memory-mapped FPU to be faster than pure software calculation. Otherwise it would not make much sense to develop such a device, or to support it in libraries. But it will still be much slower than a "real" FPU.

As to applications: Texel might be good candidate for it.

I've somewhere a jpeg source lying around that I used at the end of the 90s on the ATARI and Mac which should be a good test with its DCT code (if you select the accurate output options).

[pixelpusher]

Some time ago I stumbled over the archive for fpu_emu (.zip) by H. Robbers & V. Hemsen. While being limited to support the memory mapped 68881 via LineF, it allows using the same FPU code that you would have used on system with 68020 (or newer) with FPUs.

We just discussed a similar program (once published in c't magazine) over at AF: https://www.atari-forum.com/viewtopic.php?f=14&t=40516

After finding out that the fpu_emu from Robers & Hemsen doesn't pass exxos' FPUTEST program, I digged further and found this discussion (it's in german ...): https://groups.google.com/g/maus.sys.at ... 3bLO0-EegJ

discussing two other alternatives (all of them based on the original c't magazine method). Of those two only one was ever published (LFED - with sources) and it passes exxos' FPUTEST completely. It still stumbles in GB 6, as GB 6 doesn't support the _FPU cookie being set to "LineF emulation present + SFP 004 present; in fact even patching that to LineF emulation present + 68881 wasn't sufficient; GB only accepts it if the low-word is zero). With that GB starts but triggers a crash later (so most likely something in the emulation isn't on spot or GB6 tests one of the 3 not supported instructions).

Anyway, LFED otherwise looks quite promising (see above google link). Speed for simple fadd/fsub instructions is about 1.5x slower than using SFP-004 (both still being faster than software float libs), but surprisingly trigonometric functions seem to execute faster with LFED than the SFP-004 support used by the C compiler (not true for assembler coding though).

[exxos]

I will have a look at GB6 FPU detection when I get home later. Also IIRC the FPU tests were done to be compatible between across all FPU setups. Also IIRC the 060 only had a basic list of internal instructions, so instructions were used which would be most compatible across all "types" of FPU.

[pixelpusher]

I will have a look at GB6 FPU detection when I get home later. Also IIRC the FPU tests were done to be compatible between across all FPU setups. Also IIRC the 060 only had a basic list of internal instructions, so instructions were used which would be most compatible across all "types" of FPU.

Thx! Let me know if I should upload the archive with LFED here (zip including sources + binary is only 68 kb) for testing...

[exxos]

Thx! Let me know if I should upload the archive with LFED here (zip including sources + binary is only 68 kb) for testing...

This is what GB6 does..

Code: Select all

'I/O mapped FPU = 68000 + FPU
'line F built in FPU into CPU ot 688881/2

DEF fpu$
STATIC fpu&
IF GETCOOKIE("_FPU",fpu&) THEN
   IF     fpu&=&h10000 THEN
      fpu$="I/O mapped FPU"

   ELSEIF fpu&=&h20000 THEN ' 68881/2 external
      fpu$="LineF FPU inst." 

   ELSEIF fpu&=&h30000 THEN ' 68881/2 external
      fpu$="LineF FPU inst."
 
   ELSEIF fpu&=&h40000 THEN ' 68881/2 external
      fpu$="LineF FPU inst." 

   ELSEIF fpu&=&h50000 THEN ' 68881/2 external
      fpu$="LineF FPU inst." 

   ELSEIF fpu&=&h60000 THEN ' 68881/2 external
      fpu$="LineF FPU inst." 

   ELSEIF fpu&=&h70000 THEN ' 68881/2 external
      fpu$="LineF FPU inst." 

   ELSEIF fpu&=&h80000 THEN ' internal FPU 68040
      fpu$="Internal FPU" 

   ELSEIF fpu&=&h90000 THEN ' internal FPU 68040
      fpu$="Internal FPU"

   ELSEIF fpu&=&h100000 THEN ' internal FPU 68060
      fpu$="Internal FPU"

   ELSEIF fpu&=0 THEN
      fpu$="FPU Not present"
   ELSE
      fpu$="Cookie =$"+HEX$(fpu&)
   END IF
ELSE
   fpu$="FPU not present"
END IF
END DEF

I don't really remember where that information came from tho..

[pixelpusher]

Thx! Let me know if I should upload the archive with LFED here (zip including sources + binary is only 68 kb) for testing...

This is what GB6 does..

Code: Select all

'I/O mapped FPU = 68000 + FPU
'line F built in FPU into CPU ot 688881/2

DEF fpu$
STATIC fpu&
IF GETCOOKIE("_FPU",fpu&) THEN
   IF     fpu&=&h10000 THEN
      fpu$="I/O mapped FPU"

   ELSEIF fpu&=&h20000 THEN ' 68881/2 external
      fpu$="LineF FPU inst." 

   ELSEIF fpu&=&h30000 THEN ' 68881/2 external
      fpu$="LineF FPU inst."
 
   ELSEIF fpu&=&h40000 THEN ' 68881/2 external
      fpu$="LineF FPU inst." 

   ELSEIF fpu&=&h50000 THEN ' 68881/2 external
      fpu$="LineF FPU inst." 

   ELSEIF fpu&=&h60000 THEN ' 68881/2 external
      fpu$="LineF FPU inst." 

   ELSEIF fpu&=&h70000 THEN ' 68881/2 external
      fpu$="LineF FPU inst." 

   ELSEIF fpu&=&h80000 THEN ' internal FPU 68040
      fpu$="Internal FPU" 

   ELSEIF fpu&=&h90000 THEN ' internal FPU 68040
      fpu$="Internal FPU"

   ELSEIF fpu&=&h100000 THEN ' internal FPU 68060
      fpu$="Internal FPU"

   ELSEIF fpu&=0 THEN
      fpu$="FPU Not present"
   ELSE
      fpu$="Cookie =$"+HEX$(fpu&)
   END IF
ELSE
   fpu$="FPU not present"
END IF
END DEF

I don't really remember where that information came from tho..

This link contains the documentation for the _FPU cookie: http://toshyp.atari.org/en/003007.html#Cookie_2C_20_FPU

For the lower word (that your code always checks to be zero) it says:

The lower WORD is reserved for information about software support via the Line-F trap, and is at present not yet in use. According to Atari, a non-zero value indicates that Line-F support is present.

Can you spill some info what fpu code is called in your test?

[exxos]

For the lower word (that your code always checks to be zero) it says:

The lower WORD is reserved for information about software support via the Line-F trap, and is at present not yet in use. According to Atari, a non-zero value indicates that Line-F support is present.

I haven't been following this thread too closely and not sure what the software emulation is exactly doing.. I can add a bit0 check for =1 (is that regardless of all other bits ?) if you're saying it will run LINEF type instructions, but that could crash GB6 if it's not emulating exactly like a real FPU via LINEF. Of course IO mapped isn't supported at all.

Can you spill some info what fpu code is called in your test?

Code: Select all

*-----------------------------------------------------------------------------*
*	Float FMUL,FDIV,FADD,FNEG,FSQRT,FCMP,FABS,FREM combined speed test
*-----------------------------------------------------------------------------*
fprim_test:
*-----------------------------------------------------------------------------*
	move.l		bas_params(pc),d2
	subq.l		#1,d2
	bmi.s		.err
	fmovem		fp0-fp7,-(sp)
.fprim_outer_loop:
	fmove.s		#1.001,fp0
	fmove.x		fp0,fp1
	fmove.x		fp0,fp2
	fmove.x		fp0,fp3
	fmove.x		fp0,fp4
	fmove.x		fp0,fp5
	move.w		#(1024/8)-1,d1 ; 1024 loops
.fprim_loop:
	;
	fmul.x		fp2,fp3
	fdiv.x		fp4,fp5
	fadd.x		fp0,fp1
	fneg.x		fp5
	fsqrt.x		fp3
	fcmp.x		fp4,fp5
	fabs.x		fp1
	frem.x		fp3,fp4
	;
	dbra		d1,.fprim_loop
	dbra 		d2,.fprim_outer_loop
	fmovem		(sp)+,fp0-fp7
.err:	rts

[pixelpusher]

if your saying it will run LINEF type instructions, but that could crash GB6 if it's not emulating exactly like a real FPU via LINEF. Of course IO mapped isn't supported at all.

The LineF emulation should make the machine behave as if the FPU was integrated on machines with 68020 or newer cpus and above code should just work. So if nothing quirky is done in GB (the posted code looks fine), then it's something to investigate and fix in the LineF emulation.

Regarding the checks: Yes, the lower word of the FPU cookie being 0x0001 is being set by this emulator, indicating that LineF based FPU opcodes can be used and the upper word still shows that the hardware for this is based on the SFP-004 (so this wouldn't show if a 68882 is used in a SFP-004 compatible hw, but that's not a priority problem atm). Note that ATARI said "any non-zero value indicates Line-F support", so 0xffff would have been fine too.

[exxos]

The LineF emulation should make the machine behave as if the FPU was integrated on machines with 68020 or newer cpus and above code should just work. So if nothing quirky is done in GB (the posted code looks fine), then it's something to investigate and fix in the LineF emulation.

OK will try and do a patch to GB6 later today. Hisoft doesn't have a Bit test function, so will have to code one