68881 FPU FMOVECR test

[Toni Wilen]

Another test, this time hardware requirements are: real Amiga with 68020 or 68030 + 68881 FPU. (I only have 68882)

Run attached program (source also included), it creates 4096 byte file named fmovecr.bin in current directory, attach or email the file.

FMOVECR has many undocumented constants and I'd like to know if they are mostly same as in 68882 (most undocumented fields are zeros in 68882) or totally different.

EDIT: Test updated, more information includes (16k output now)

[Matt_H]

If you were not already aware, a bit of work has been done in this area. See: http://aminet.net/package/misc/misc/fmovecr_dump

Perhaps you and the other author can compare notes

[Toni Wilen]

Yes, I know but it does it wrong, it returns rounded values.

[Toni Wilen]

I forgot (not the first time) that I have A500 68020 accelerator with 68881 (Apollo 520). Unexpectedly all FMOVECR offsets are 100% identical to 68882.

Test results still accepted for confirming this 100%. (If there are different revisions)

[jotd]

user manual states

Offset Constant
$00 'IT
$08 L0910(2)
$OC e
$OD L092(e)
$OE L091O(e)
$OF 0.0
$30 In(2)
$31 1 n(10)
$32 100
$33 101
$34 102
$35 104
$36 108
$37 1016
$38 1032
$39 1064
$3A 10128
$38 10256
$3C 10512
$3D 101024
$3E 102048
$3F 104096
The on-chip ROM contains other constants useful only to the on-chip microcode routines.
The values contained at offsets other than those defined above are reserved for the use of
Motorola, and may be different on various mask sets of the FPCP.

probably varying even from one rev of 68881 or 68882 to another or I understand wrong?

[Toni Wilen]

Originally Posted by jotd

probably varying even from one rev of 68881 or 68882 to another or I understand wrong?

It was confirmed later: undefined values are 100% identical between 68881 and 68882.

Only undefined entries between 1 to 10 have unique value. All other undefined entries contain same value.

[mschulz]

Originally Posted by jotd

user manual states
...

Aaaah, this badly OCR-ed scanned paper manuals. What you pasted is highly misleading... Here corrected table:

Offset Constant
$00 Number Pi
$0B Log10(2)
$OC e
$OD Log2(e)
$OE Log1O(e)
$OF 0.0
$30 Ln(2)
$31 Ln(10)
$32 1E0
$33 1E1
$34 1E2
$35 1E4
$36 1E8
$37 1E16
$38 1E32
$39 1E64
$3A 1E128
$38 1E256
$3C 1E512
$3D 1E1024
$3E 1E2048
$3F 1E4096

[jotd]

okay then nitpicking your Log1O(e) which should be Log10(e). That was just a quick copy/paste because the blurb below made me wonder about those undocumented values.

I just wonder what's the point of values like 10^4096... specially when you can't even possibly store that in a "double" IEEE format by far (AFAIR double ranges up to 10^338 only).

And also why are there ROM constants for 0 and 1? isn't that trivial with simple FMOVE.X #1e0,FPx ? or maybe it's easier if you don't have an assembler that doesn't understand floating point?

I also wonder why values like 0.5, 0.25 ... (negative powers of 2) aren't in the constants. They're often used too.

[mschulz]

Originally Posted by jotd

okay then nitpicking your Log1O(e) which should be Log10(e).

Oh, I have overseen that one.

Originally Posted by jotd

Anyone with a tiny background in math figures out the OCR errors. Others don't give a damn abour Neper and his friends

Not always, I was already filling a bug report and PR to a project where, thanks to OCR-ed manual, someone put number 100 to a 68881 rom constant where a 10^0, or 1E0 or just 1.0 should be written

Originally Posted by jotd

I just wonder what's the point of values like 10^4096... specially when you can't even possibly store that in a "double" IEEE format by far (AFAIR double ranges up to 10^338 only).

68881/2 work in extended 80bit formal internally. There, 1E4096 fits.

Originally Posted by jotd

And also why are there ROM constants for 0 and 1? isn't that trivial with simple FMOVE.X #1e0,FPx ?

FMOVECR is a 4-byte instruction. FMOVE.X #1e0, FPx is 16-byte instruction (4 bytes for fmove, 12 bytes for immediate in EA). Additionaly, fmovecr is faster, uses less bus cycles etc.

Originally Posted by jotd

I also wonder why values like 0.5, 0.25 ... (negative powers of 2) aren't in the constants. They're often used too.

Simple positive and negative powers of two are less often used then the constants existing already. besides, for very wide range of powers they can be already properly written in single type without rounding, which is due to nature of IEEE numbers, not necessary for any power of two fitting in the floating point number.

[jotd]

makes sense. The size argument part is deadly when emulated: on a 68040/060 it takes at least 20 instructions to decode the FMOVECR and put a real value instead.

Direct patching is better in that case. For COS/SIN, all trig functions I'm less sure that the trap handling & other overhead is significant.

Of course also right about powers of 2. But inverted powers of ten would fit nicely in here.

Anyone with a tiny background in math figures out the OCR errors. Others don't give a damn abour Neper and his friends

I had edited that part out, found that slightly condescending. Sorry you had to read it.

[Thomas Richter]

Originally Posted by mschulz

68881/2 work in extended 80bit formal internally. There, 1E4096 fits.

The reason why these powers of ten are in the constant ROM is that they are needed for the conversion of packed decimal to IEEE extended precision and back.

[alexh]

There were 6 mask sets for 68882 dating from 1989 through to 1989

4B96M <- 1989 MC Parts
1C12R <- 1988/89 XC Parts
0C35H <- 1990 MC parts
5896M
2C12R <- 94 MC
1J23S <- 99 MC (Last mask)

But I am told that all of them are 100% identical functionality. Even the XC parts.

[Thomas Richter]

Originally Posted by alexh

1C12R <- 1988/89 XC Parts
0C35H <- 1990 MC parts

Are you sure you didn't mix these two up? I have here a 1C12R mask that is qualified as MC-part, not as XC part. It would make more sense if 0C35H is the earlier mask.

[Toni Wilen]

I have 4B96M (MC68882RC20A) with date code 8912.

[alexh]

Originally Posted by Thomas Richter

Are you sure you didn't mix these two up? I have here a 1C12R mask that is qualified as MC-part, not as XC part. It would make more sense if 0C35H is the earlier mask.

Maybe. I collated the data a long time ago. I imagine there is always an overlap between manufacturing lines, packaging etc. Also it is possible that they ran the fabs in parallel. There are a few faster parts which are obvious Chinese rebranded parts.

If there was functionally only one design, which I was told there was, I can imagine Motorola could mark die made with a mask set previously marked XC as MC.

Here are a few images:

[alexh]

Originally Posted by Toni Wilen

I have 4B96M (MC68882RC20A) with date code 8912.

Yes I think you are right. I misread the date code.