68000 and floating point

[kerravon]

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.

[pandy71]

Originally Posted by kerravon

From reading Wikipedia there was no option to add a floating point coprocessor to an Amiga 500.

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.

[jotd]

you can still emulate floating point by software. It doesn't have to be by hardware.

gcc has a -msoft-float switch.

[kerravon]

Originally Posted by pandy71

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.

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?

[kerravon]

Originally Posted by jotd

you can still emulate floating point by software. It doesn't have to be by hardware.

gcc has a -msoft-float switch.

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?).

[jotd]

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.

[No.3]

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.

Originally Posted by kerravon

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 do not know in which world you life, but it is obviously not the Amiga world.

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.

[kerravon]

Originally Posted by No.3

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.

Which is the normal reason to be asking questions?

I do not know in which world you life, but it is obviously not the Amiga world.

Largely I am from a mainframe (S/370) and PC (x86) background and in both cases I always assume there is a coprocessor available (and on the mainframe at least there always is).

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.

I don't mind the end user having to pay a price for running floating point software on a machine with no coprocessor - they are lucky it works at all.

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.

I assume these libraries cause code to be linked in to my executables. Copyrighted code most likely. I want my executables to be pure public domain - every byte.


You may not agree with that goal - but that's my goal and it is quite normal for people to have different goals.

[Steady]

@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.

[kerravon]

Originally Posted by Steady

@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.

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.

[kerravon]

Originally Posted by jotd

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.

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).

[meynaf]

Originally Posted by kerravon

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.

FPU is inbuilt starting with 68040. But not having it is neither rare nor impossible. There are Amiga programs that provide two versions : FPU and no FPU.
Strictly requiring FPU on the Amiga will leave quite a lot of users behind.

Originally Posted by kerravon

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).

Atari ST apps certainly do TRAPs. And quite a lot of them, actually (trap #1, trap #2, trap #13, trap #14, even line-A).

[kerravon]

Originally Posted by meynaf

FPU is inbuilt starting with 68040. But not having it is neither rare nor impossible.

Well it's impossible to have no FPU if you are using a 68040 or above.

There are Amiga programs that provide two versions : FPU and no FPU.
Strictly requiring FPU on the Amiga will leave quite a lot of users behind.

It is only if you have a C90-compliant program (that also follows the "D7 standard") that does floating point that this issue would arise. Most of my applications don't use floating point.


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.

Atari ST apps certainly do TRAPs. And quite a lot of them, actually (trap #1, trap #2, trap #13, trap #14, even line-A).

Ok, thanks. In that case the same technique can't be used to create a mini Atari clone, and I will probably standardize on the Amiga (ie not Atari and not Linux) for my executables (and use that ixemul or whatever it is called shared library for the C runtime to reduce the size - eventually).


And that would be my development environment (emulated of course - I'm actually using a Pinebook Pro (ARM 32/64) for development).

[meynaf]

Originally Posted by kerravon

Well it's impossible to have no FPU if you are using a 68040 or above.

No. Check for 68LC040.

Originally Posted by kerravon

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.

Perhaps you need to read this thread.

[jotd]

There are some 060s without FPU. 680LC60. They benefit from motorola FPU emulation libraries though.

[kerravon]

Originally Posted by meynaf

No. Check for 68LC040.

Thanks.

Perhaps you need to read this thread.

Looks exactly what is needed for real hardware for what I want to do.


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.

[No.3]

Originally Posted by kerravon

I assume these libraries cause code to be linked in to my executables. Copyrighted code most likely. I want my executables to be pure public domain - every byte.

=>

Originally Posted by No.3

you don't seem to have a clue how the amiga works and how to program it

Originally Posted by kerravon

Largely I am from a mainframe (S/370) and PC (x86) background and in both cases I always assume there is a coprocessor available (and on the mainframe at least there always is).

In this case better program PCs and mainframes.


Number one and most important rule when programming the Amiga: do not assume anything

[Cyprian]

68000 has no external FPU support, but 68881/2 can be memory mapped.
E.g. Atari ST 68881/2 register mapping:

##############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)

and example how to use it:
https://www.chzsoft.de/site/site/ass...ari_sfp_en.pdf

[No.3]

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.

[Photon]

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".