19 May 2024, 21:40 | #1 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
68000 and floating point
I have limited knowledge about floating point, but the C90 standard mandates floating point.
I'm mainly interested in the Amiga 500 (which is what I had back in the day - around 1988). Currently I am building my C library (PDPCLIB) with gccami -m68020 as I don't want the multiply instructions to cause external routines to be called in which I don't have public domain code for. But I'm going to have another attempt at that. So assuming I get 68000 to work - including multiply routines - then the next thing I need is floating point. From reading Wikipedia there was no option to add a floating point coprocessor to an Amiga 500. There was an expansion port where you could add a 68020 though. Or even directly on the machine it seems. Based on that, I could switch to 68020 as a minimum I guess - but I'm not really concerned if multiply operations are slow, so I'd prefer to stick to 68000. But regardless, this still isn't floating point. I am aware I could generate soft float, but I don't want to do that. I believe the way things normally work is that you can generate hard float even for a machine without a coprocessor, and then the CPU traps, and you can have a trap handler which does the soft float for you and then returns to the executing program. I remember reading about some machine that didn't have the ability to continue executing after a fault, so that virtual memory couldn't be implemented, but I don't remember which machine that was, so that's presumably not relevant. With the Amiga 2000 (actually 2500/20) there is the first sign of a coprocessor - 68881. That was in 1988 - the sort of time period I am interested in. So perhaps I could target the 2500/20, but for non-floating point, restrict myself to 68000 instructions, so that my software runs on an Amiga 500, unless floating point is used, and then it either crashes, or the trap handling (possibly I would rely on a 3rd party for this) works. I don't particularly mind my software crashing if it uses floating point, as that is more of a sign I should be producing an integer version of the software. But it would be nice if it worked, and was just slow. So - do I have the concepts right that I should be attempting to get (my fork of) gcc 3.2.3 to generate 68000 and 68881 code and then it would work on all Amigas if appropriately configured? Basically I am belatedly setting up my Amiga 500 development environment to catch the Commodore wave. Thanks. Paul. |
19 May 2024, 21:59 | #2 |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,911
|
This is incorrect - there is application note from Motorola "AN947 MC68881 Floating-Point Coprocessor as a Peripheral in a M68000 System" [Motorola 1987]. You can add other numeric processors in similar fashion (peripheral), coprocessor interface is supported from 68020.
|
19 May 2024, 22:00 | #3 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,410
|
you can still emulate floating point by software. It doesn't have to be by hardware.
gcc has a -msoft-float switch. |
19 May 2024, 22:07 | #4 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Sorry - could you clarify that? For the Amiga 500 specifically, did someone sell a "peripheral" that had a 68881? It wasn't mentioned on Wikipedia. And what is it that was supported "from 68020" if the 68000 already supported it? ie what changed with the 68020 that made you mention it? |
|
19 May 2024, 22:09 | #5 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Yes - I don't want those routines (or even public domain replacements) linked into my executables. I want floating point instructions to be used so that it is fast on an appropriate machine. If you don't have an appropriate machine, I'm happy for it to crash until you install 3rd party software (assuming that it is technically possible to have 3rd party software that handles hard floats in an executable on a machine with no 68881 coprocessor - is it technically possible?). |
|
19 May 2024, 22:48 | #6 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,410
|
it is possible as missing 68881 instructions will trigger ILLEGAL/LINE-A/F whatever so they could be intercepted and processed by software
that's exactly how oxypatcher and other resident programs handle the missing 68030 instructions on 68040/68060. But to my knowledge no such thing exists for 68000. |
19 May 2024, 22:50 | #7 | |
Registered User
Join Date: Sep 2022
Location: Switzerland
Posts: 120
|
kerravon, don' take it the wrong way, but you don't seem to have a clue how the amiga works and how to program it.
This thread seems to be in context with the "PDOS for Amiga" thread where I can not read your posts without shaking my head in disbelief. e.g. Quote:
You can do it this way, but then you need third party software which does the FPU emulation and not only the emulation but catching all the traps will be horribly slow. So why don't you do it the Amiga Way ?! Amiga OS offers several math libraries and these math libraries use the FPU if one is available otherwise the CPU is used to do the floating point calculations. |
|
20 May 2024, 02:29 | #8 | ||||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Quote:
Quote:
Quote:
You may not agree with that goal - but that's my goal and it is quite normal for people to have different goals. |
||||
20 May 2024, 05:18 | #9 |
Registered User
Join Date: May 2021
Location: Melbourne, Australia
Posts: 46
|
@kerravon
No, you would not need to link external copyrighted code to use the Amiga math libraries. You can call directly via registers or create your own stubs if you worry about linking with amiga.lib (I wouldn't). The actual libraries are supplied by the OS itself. You just call into them which does not affect your program being public domain. |
20 May 2024, 05:41 | #10 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Ok, thanks. That would be a reasonable option. So gcc 3.2.3 with the soft-float option would be implemented as stubs to call into the Amiga libraries. That's still not what I really expect though. I expect hard floats, which are of maximum efficiency for people who want to use floating point. And I basically expect people to buy a coprocessor if they care about performance, or be grateful for whatever they get if they're not prepared to buy a coprocessor. And I assume on more modern 68k-based machines that it is rare or impossible to not have a coprocessor. That's what happened with the 80486 - floating point was inbuilt. |
|
20 May 2024, 07:42 | #11 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Thanks for that. And this is normal practice on other platforms, right? I've been thinking more about it and I think I want to target the 68020/68881, which is where I started with vbcc incidentally: CC=vbccm68k COPTS=-D__AMIGA__ -cpu=68020 -fpu=68881 -O=991 -I. -I../amiga It is the 68020 where the op codes were assigned for 32-bit divide, the same as the 68881 was when the op codes were assigned for floating point, and if you wish to run on the cheaper 68000 then I think it is reasonable that you need to pay a performance penalty. I think the code generation should be such that the m68k is a competitor for the 80386 + 80387, and it's a fairly simple matter of buying an A2500/20. The 68020 was US$487 in 1984 so it was affordable if you prioritized appropriately and could have added that to an Amiga 500 too. And a software option (done the same as oxypatcher) if you want to save even on that. 32-bit divides probably aren't a big part of your application anyway. I think that makes for clean m68k executables for my C90-compliant programs. And then I would build Amiga Hunks as PDOS-generic apps and run them under the pseudo-bios. A pseudo-bios that can also be made available on an Atari ST with minimal fuss. So in the end I would expect to be able to run D7-compliant Amiga executables on either the Atari or Amiga, and PDOS-generic apps on both environments as well. Not sure if I can also run "certain" standard Atari apps as well (potentially under the same pseudo-bios). It would depend on what they are expecting on entry and whether they do TRAPs (which my design can't handle). |
|
20 May 2024, 09:29 | #12 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,377
|
Quote:
Strictly requiring FPU on the Amiga will leave quite a lot of users behind. Atari ST apps certainly do TRAPs. And quite a lot of them, actually (trap #1, trap #2, trap #13, trap #14, even line-A). |
|
20 May 2024, 09:50 | #13 | |||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Quote:
And for the situations where floating point is indeed used - then the solution I would want is the same as the oxy-thing - you separately run a TSR or whatever the equivalent is on the Amiga to handle the exceptions. Which I thought was normal practice on other platforms. Quote:
And that would be my development environment (emulated of course - I'm actually using a Pinebook Pro (ARM 32/64) for development). |
|||
20 May 2024, 10:08 | #14 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,377
|
Quote:
Quote:
|
||
20 May 2024, 10:09 | #15 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,410
|
There are some 060s without FPU. 680LC60. They benefit from motorola FPU emulation libraries though.
|
20 May 2024, 11:08 | #16 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Thanks.
Quote:
Note that if I was to generate soft floats in gcc and get them to call the maths library in the Amiga - I would then need to (in my own Amiga mini-clone) convert those calls back to the original instructions so that they can be run on my actual environment (Pinebook Pro running qemu-m68k - not system). Sure it's doable, but not really what I want. So the SoftIEEE does what I want, and then I need that Oxy thing extended to include whatever the divide instructions on the 68020 are (that aren't present on the 68000). Is the Oxy author likely to be willing to do that? Well - technically I don't need that immediately - I'm not using real hardware so it's more a theoretical use case on a real 68000 (or if I restrict qemu to 68000). So I guess it's more something to "pencil in" to be written when actually required. Combined with softieee. I assume two TSRs (or whatever) can be active at the same time. |
|
20 May 2024, 15:31 | #17 | |||
Registered User
Join Date: Sep 2022
Location: Switzerland
Posts: 120
|
Quote:
Quote:
Quote:
Number one and most important rule when programming the Amiga: do not assume anything |
|||
20 May 2024, 16:30 | #18 |
Registered User
Join Date: Jul 2014
Location: Warsaw/Poland
Posts: 196
|
68000 has no external FPU support, but 68881/2 can be memory mapped.
E.g. Atari ST 68881/2 register mapping: Code:
##############Floating Point Coprocessor (CIR Interface in MSTe) ########### -------+-----+-----------------------------------------------------+---------- $FFFA40|word |FP_Stat Response-Register |??? (MSTe) $FFFA42|word |FP_Ctl Control-Register |??? (MSTe) $FFFA44|word |FP_Save Save-Register |??? (MSTe) $FFFA46|word |FP_Restor Restore-Register |??? (MSTe) $FFFA48|word | |??? (MSTe) $FFFA4A|word |FP_Cmd Command-Register |??? (MSTe) $FFFA4E|word |FP_Ccr Condition-Code-Register |??? (MSTe) $FFFA50|long |FP_Op Operand-Register |??? (MSTe) $FFFA54|word |FP_Selct Register Select |??? (MSTe) $FFFA58|long |FP_Iadr Instruction Address |??? (MSTe) $FFFA5C|long | Operand Address |??? (MSTe) https://www.chzsoft.de/site/site/ass...ari_sfp_en.pdf |
20 May 2024, 16:49 | #19 |
Registered User
Join Date: Sep 2022
Location: Switzerland
Posts: 120
|
There were a very few "CPU Boards" which provided a 68881 along to a 68000 (68010): https://amiga.resource.cx/search.pl?product=68881
But no, this is not the way how to use floating point math on an Amiga. |
20 May 2024, 17:45 | #20 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,752
|
C was hacky in the 80s and 90s. I'm not familiar with C90, but C also rolled its own string and memory handling, dispensed with strict typing, atom definition, etc. Engineering specifications like IEEE arose to standardize all the individual floating-point calculation implementations for precision, consistency, calling conventions, etc. I don't know if C picked up a standard until later.
Libs accelerate the creation of a language on Amiga greatly, and are there to help devs not do something that is incompatible with the design of AmigaOS. They are like a BIOS+++. Only a few are strictly necessary for a language targeting AmigaOS (such as Intuition). This was an attempt to avoid what C got: everyone and his brother made their own "libs" which weren't compatible and weren't compiled, and it was a huge mess. But you ARE free to create any libs you desire, and they can be called just as easily as the ones that come with AmigaOS. Since there are standard libraries for floating-point though, it's recommended to support existing libraries and if speed or bugfixing is desired, to patch the existing libs outside of your language or application. The upside to this is that each user will have libs that work well on their setup, and the applications can be oblivious to (abstracted from) the specific setup and call the functions opaquely. Amiga libraries are standalone and distributed with the OS. As such, together they function as something like a public, documented API. Devs are not expected to compile or link them, or redistribute them. This means that they don't have to be part of your distributed executable, but also that the burden is on you to either specify an OS version and stick to that, or check the version of AmigaOS (technically, the lib version) for those lib functions that have been changed or added over time, to support older versions "and up". |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Pseudo Floating Point | Ernst Blofeld | Coders. General | 29 | 09 February 2021 20:03 |
StormC4 - floating-point number | emufan | Coders. C/C++ | 0 | 11 November 2017 21:32 |
Fast floating-point random numbers | Leffmann | Coders. Tutorials | 27 | 25 August 2016 01:59 |
Important Facts about Floating Point Numbers | Mrs Beanbag | Coders. General | 2 | 13 August 2016 21:14 |
Floating point without FPU | oRBIT | Coders. Asm / Hardware | 13 | 18 March 2015 23:11 |
|
|