English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 05 August 2017, 23:07   #1
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,630
68881 FPU FMOVECR test

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)
Attached Files
File Type: zip fmovecrtest.zip (970 Bytes, 172 views)

Last edited by Toni Wilen; 07 August 2017 at 20:43. Reason: Test updated
Toni Wilen is offline  
Old 05 August 2017, 23:27   #2
Matt_H
Registered User
Matt_H's Avatar
 
Join Date: Jul 2008
Location: Boston, MA
Posts: 375
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
Matt_H is offline  
Old 05 August 2017, 23:32   #3
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,630
Yes, I know but it does it wrong, it returns rounded values.
Toni Wilen is offline  
Old 06 August 2017, 13:05   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,630
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)
Toni Wilen is offline  
Old 15 January 2021, 01:11   #5
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 5,098
user manual states

Code:
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?
jotd is offline  
Old 15 January 2021, 09:22   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,630
Quote:
Originally Posted by jotd View Post
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.
Toni Wilen is offline  
Old 15 January 2021, 09:39   #7
mschulz
Registered User

 
Join Date: Nov 2018
Location: Germany
Posts: 18
Quote:
Originally Posted by jotd View Post
user manual states
...
Aaaah, this badly OCR-ed scanned paper manuals. What you pasted is highly misleading... Here corrected table:

Code:
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
mschulz is offline  
Old 15 January 2021, 09:46   #8
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 5,098
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.
jotd is offline  
Old 15 January 2021, 09:51   #9
mschulz
Registered User

 
Join Date: Nov 2018
Location: Germany
Posts: 18
Quote:
Originally Posted by jotd View Post
okay then nitpicking your Log1O(e) which should be Log10(e).
Oh, I have overseen that one.

Quote:
Originally Posted by jotd View Post
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

Quote:
Originally Posted by jotd View Post
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.

Quote:
Originally Posted by jotd View Post
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.

Quote:
Originally Posted by jotd View Post
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.

Last edited by mschulz; 15 January 2021 at 09:58.
mschulz is offline  
Old 15 January 2021, 11:17   #10
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 5,098
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.

Quote:
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.

Last edited by jotd; 15 January 2021 at 11:22.
jotd is offline  
Old 15 January 2021, 13:09   #11
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 964
Quote:
Originally Posted by mschulz View Post
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.
Thomas Richter is offline  
Old 15 January 2021, 22:32   #12
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 12,591
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.

Last edited by alexh; 16 January 2021 at 18:17.
alexh is offline  
Old 16 January 2021, 17:13   #13
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 964
Quote:
Originally Posted by alexh View Post
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.
Thomas Richter is offline  
Old 16 January 2021, 17:34   #14
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,630
I have 4B96M (MC68882RC20A) with date code 8912.
Toni Wilen is offline  
Old 16 January 2021, 17:53   #15
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 12,591
Quote:
Originally Posted by Thomas Richter View Post
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:





Last edited by alexh; 16 January 2021 at 18:18.
alexh is offline  
Old 16 January 2021, 18:16   #16
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 12,591
Quote:
Originally Posted by Toni Wilen View Post
I have 4B96M (MC68882RC20A) with date code 8912.
Yes I think you are right. I misread the date code.

alexh is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Considering replacing 68881 with 68882 B14ck W01f support.Hardware 16 24 July 2016 08:01
Maths library for 68881? allanmb Amiga scene 3 29 September 2015 10:59
68881 Fpu Lord Aga support.Hardware 2 18 November 2011 22:49
ELSA E1208+8mb+copro 68881 frikilokooo support.Hardware 13 27 September 2007 22:13
Demo for overclocked FPU Test fc.studio request.Demos 2 28 August 2007 12:42

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 22:12.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.11507 seconds with 16 queries