Why no love for MC68LC060?

[Mathesar]

Last year I finalized my A3660 build for my A3000.
I used an 68LC060 without FPU. Reason being that I didn't need to change my ROM's and because they are cheaper than full 060's.

However, I noticed that there seems not to be a lot of love for the humble 68LC060.
But what's not to like? They are cheap and easy to find on ebay. Given that full 060's are getting epensive and rare the LC060 seems like a decent alternative for Amiga accelerators. I looked around a bit on ebay and prices for full 060's are really going through the roof. (for accelerators as well, just look at this item: https://www.ebay.nl/itm/Cyberstorm-M...YAAOSwDMVdKa8I)
I got my 680LC060 for just $34 including shipping I also got the feeling 68LC060 are less often fakes, all the ones I find on ebay seem to be the 75G59Y mask as is mine. WhichAmiga says it is a rev4.

All in all I am very happy with it and my A3000 runs like a charm. Workbench runs very smooth (thank you Peter for your icon.library ), gloom runs decently fast, I can listen to MP3's at full quality using mpega and Ibrowse is very usable. A very nice upgrade for the money.

Ok, true, one nag then, I do hope amissl V4 is fixed soon to work without an FPU. But that is really the only case where I missed an FPU. Also, there are indeed some 060 optimized programs that choke when they discover there is no FPU. The solution for that is to simply install the general 020 or 040 versions. I remember from back in the day when I still had a full 060 that it often didn't make a lot of difference in speed.

So, any thoughts? Any love for the LC060? Or the need for an FPU on the Amiga in general?

[quantum8]

I guess it depends on what you want to do! Pretty sure games like quake require an FPU , as would a lot of 060 demos. But if you can live without that then there's no issue.

[Minuous]

Is there an external FPU that can be used in conjunction with that CPU?

[Misclegend]

in my A1200 I had an apollo 1260 at 66mhz which had the LC060 without fpu

but I sold that turboboard because was a headdache
I never liked it because all the 060 incompatibilities with games and programs and the lack of fpu which prevents lot of programs,plugins, datatypes etc to work

The best CPU for any Amiga is yet the 040/40 mhz which is yet very fast and much more compatible than any 060

[Thomas Richter]

Originally Posted by Minuous

Is there an external FPU that can be used in conjunction with that CPU?

Nope. The coprocessor interface is only available on the 68020 and 68030.

[Thomas Richter]

Originally Posted by Misclegend

I never liked it because all the 060 incompatibilities with games and programs and the lack of fpu which prevents lot of programs,plugins, datatypes etc to work

Huh, which datatype requires a FPU? As far as the system is concerned, there is nothing that requires an FPU - the programs that require math go through the mathieee libraries.

[Misclegend]

Originally Posted by Thomas Richter

Huh, which datatype requires a FPU? As far as the system is concerned, there is nothing that requires an FPU - the programs that require math go through the mathieee libraries.

there are some programs which requires FPU
there are not many but exists
ie Simplemail which is still the best amiga mailer requires FPU
also there are plugins/datatypes/programs which the author do not specify requires FPU , will crash because of that, then you will realize requires FPU

also you can't play clickboom Quake or Duke nukem 3d in Fusion or shapeshifter
thos games requires FPU

[Photon]

It's fast and cheap. Some chip masks can probably be overclocked quite a bit too. It would fit the bill and belong in an A1200/A3000/A4000 just like say ACA1233n or other FPU-less 030/040 would, but be a lot faster of course!

I guess if you go for the fastest Motorola accelerator (an 060 board) you want it to be the full version, not the budget version cos you're spending a lot of money to start with. Maybe also the people needing an 060 are also the ones who need the FPU power, and the others do fine with the above non-060s. I'm one of the former, and I wouldn't buy a FPU-less 030/040/060 accelerator unless I could upgrade it to FPU blessed.

[gulliver]

This is one of the reasons I think we should evaluate the feasability of including an FPU emulation library/service on a future version of AmigaOS.

On MacOS they had this:

https://macintoshgarden.org/apps/softwarefpu-307

On AmigaOS we had femu which was a working prototype.

Besides FPU less 68060 processors, remember there are also FPU less 68040 processors, and even some of them (the 68040V range) are pin and voltage compatible with the 68060.

Worth noting is that some programs have better output presicion when using their FPU variant (example: mpega.library).

[alexh]

There is almost no need for an FPU in any Amiga. So little software supported it (we're talking fractions of a percent). Plus there are lots of rumours and lies about software utilising an FPU when they don't. (Lots of 3D games of this era use fixed point maths)

Any other variant of 680x0 accelerator if it was an LC or didn't have the FPU fitted I wouldn't bother seeking one out.

HOWEVER

060 accelerators seem to be the exception. A higher percentage of 060 only executables have FPU code in them than any other 680x0 executable.

Which I put down to 2 things :

1) All 060 accelerators of the time had an FPU, so assembler coders could use it.

2) A higher percentage of 060 only executables are compiled from higher level languages and not assembler allowing the compiler to produce FPU code.

If it were not for 060 demo's most of which seem to use the FPU I'd not care.

Originally Posted by gulliver

I think we should evaluate the feasability of including an FPU emulation library/service on a future version of AmigaOS.

Are there not already commercial FPU emulation libraries for AmigaOS? Ones for the LC040? Possibly the LC060? I thought they were only for LC variants which had the F-Line exception hardware. But I may be completely wrong and be confusing mathlibs and oxypatcher/cyberpatcher.

[Thomas Richter]

Originally Posted by gulliver

This is one of the reasons I think we should evaluate the feasability of including an FPU emulation library/service on a future version of AmigaOS.

Thanks, but no, thanks. Just because authors are lazy and do not base their software on mathieee libraries, even if possible.

Originally Posted by gulliver

https://macintoshgarden.org/apps/softwarefpu-307

Apple also had enough paying customers that make it worthwhile, and Mac also had a critical mass of software that would profit from it. I do not know how complete this implementation is, though.

Originally Posted by gulliver

On AmigaOS we had femu which was a working prototype.

Well, far from being a FPU emulation. As far as I know, this was based on the mathieeedoubbas implementation, which is a 64-bit IEEE double precision implementation that rounds to zero (or nearest, starting with 3.2). A software FPU, however, need to support 32 bit, 64 bit, 80 bit and packed decimal, and multiple rounding modes.


There are software implementations of IEEE 754 available, even complete ones:


http://www.jhauser.us/arithmetic/SoftFloat.html



This requires, however, a compiler that supports 64 bit types and speaks a more resent version of ANSI-C. Thus, SAS/C is out.

Originally Posted by gulliver

Worth noting is that some programs have better output presicion when using their FPU variant (example: mpega.library).

Well, the mot FPUs support extended precision, the math libraries only double precision.



Getting a FPU implementation right is non-trivial, and the result will be slow, even more so if compiled from C. This will certainly be slower than using the mathieee libraries in first place. I consider the usefulness of such a software on Amiga of rather limited value.

[gulliver]

Originally Posted by Thomas Richter

Thanks, but no, thanks. Just because authors are lazy and do not base their software on mathieee libraries, even if possible.

Following that train of thought:
Then why we have NofastMem?
Then why we supported the doomsnd.library workaround?
Why do we even care about fixing bugs others made?

Authors are sometimes lazy and make mistakes: we are human after all.
We can do better.

Originally Posted by Thomas Richter

There are software implementations of IEEE 754 available, even complete ones:


http://www.jhauser.us/arithmetic/SoftFloat.html



This requires, however, a compiler that supports 64 bit types and speaks a more resent version of ANSI-C. Thus, SAS/C is out.

Great! Then why not GCC 6.x for 68k that is currently maintained?

Originally Posted by Thomas Richter

Getting a FPU implementation right is non-trivial, and the result will be slow, even more so if compiled from C. This will certainly be slower than using the mathieee libraries in first place. I consider the usefulness of such a software on Amiga of rather limited value.

"Difficult" says the man that has a degree in math. Come on Thomas!


Of course it will be slower. But it is better to have a slow working program than none at all. That is the point. Besides, many FPU less 060s are clocked at 75mhz, so the speed increase can certainly help ease the pain. Also we are no longer stuck with just 90s accelerators, current ones are much faster.

Increasing the list of working programs on Amigas is a plus for any OS.

[Mathesar]

Originally Posted by quantum8

I guess it depends on what you want to do! Pretty sure games like quake require an FPU , as would a lot of 060 demos. But if you can live without that then there's no issue.

True, 060 demos often expect an FPU. However, they often also expect AGA. So with my A3000 I can't run any of these high-end demos anyway.
I never played quake on a 060, isn't a 060 too slow for decent framerates? However, I did play Quake on my BlizzardPPC back in the day and that ran very smooth.

[gulliver]

Originally Posted by alexh

Are there not already commercial FPU emulation libraries for AmigaOS? Ones for the LC040? Possibly the LC060? I thought they were only for LC variants which had the F-Line exception hardware. But I may be completely wrong and be confusing mathlibs and oxypatcher/cyberpatcher.

Not that I know of.

[gulliver]

Originally Posted by Mathesar

True, 060 demos often expect an FPU. However, they often also expect AGA. So with my A3000 I can't run any of these high-end demos anyway.
I never played quake on a 060, isn't a 060 too slow for decent framerates? However, I did play Quake on my BlizzardPPC back in the day and that ran very smooth.

Quake on a 68060 Amiga can run from 15 to 30 fps depending on port and specific hardware configuration.

So, it is playable.

[SpeedGeek]

Originally Posted by gulliver

This is one of the reasons I think we should evaluate the feasability of including an FPU emulation library/service on a future version of AmigaOS.

The problem was not missing FPU emulation for AmigaOS. The math#?.libraries were always available. The problem was software developers not using the FPU emulation provided by these libraries.

One possible solution is an exception handler for AmigaOS which does use the FPU emulation provided, but do you know of any software developers who are willing put up with all the complaints of freaking slow exception code calling freaking slow emulation libraries?

[Thomas Richter]

Originally Posted by SpeedGeek

One possible solution is an exception handler for AmigaOS which does use the FPU emulation provided, but do you know of any software developers who are willing put up with all the complaints of freaking slow exception code calling freaking slow emulation libraries?

An exception handler that calls into the math#?.libraries is hardly a FPU emulation. It would only be able to emulate one single precision, with a single rounding mode, without proper FPU exceptions, without proper FPU status flags.


Even if we ignore this for a while and only consider simple applications: For the purpose of running a demo, this approach is completely unusable: Dog slow.

[Thomas Richter]

Originally Posted by gulliver

Following that train of thought:
Then why we have NofastMem?

It is nowadays not a very useful program at all. Applications that require it would typically not run on 3.1 or beyond anyhow, and users that want to run the rest of critical applications have found better ways of solving this problem, as in WHDload. Frankly, the only reason why it is still part of the Os is because it was always there, and it is such a small program that it does not hurt overly.

Originally Posted by gulliver

Then why we supported the doomsnd.library workaround?
Why do we even care about fixing bugs others made?

Customer experience is important, yes, but the effort for the audio.device workaround was minimal, whereas the effort for a correct FPU emulation is at least two magnitudes larger in development time. (1 day << 100 days, if not more).

Originally Posted by gulliver

Great! Then why not GCC 6.x for 68k that is currently maintained?

Look, I am not trying to stop anyone from attempting this, but if I look at the ratio between effort and result, and I see all the other problems that require a solution, then I come to the conclusion that there are more than enough problems left for the next years before this one becomes relevant.

Originally Posted by gulliver

"Difficult" says the man that has a degree in math. Come on Thomas!

Well, then let's look into the past to come to a realistic estimate: Updating the 3.1.4 math libraries from "round to zero" (with all its implications on precision) to "round to nearest, round to even" took about two weeks. Testing and debugging included.


Now, if we do this all again for extended precision, a mathieeeextbas.library would probably require 3 months or so, and then we would only have one out of the multiple rounding modes the 68881/882 support.


Then, we "only" need to emulate the "inexact" bits of the FPU, the exceptions, the comparison modes, including the "unordered" special cases, packed decimal and probably a couple of things I have forgotten.


Thus, if done from scratch, I believe the development time factor compared to the silly audio patch is probably closer to 3 magnitudes than 2.


If we take an existing "softfloat" library (as the one quoted above), then it "only" takes an exception handler. That is smoother, and probably takes "only" two months or so. While doable, the performance of the code will certainly less than ideal, certainly slower than the (already optimized!) math.libraries written in assembly, and certainly completely unsuitable for demo applications.


Frankly, the following solution is a much better one: If you have a serious application, select always the version that works without a FPU - this is typically available. There is no solution for demos or speed critical applications anyhow - a soft FPU will be slow, and a lot slower than using the math.libraries directly.


Thus, there are applications that can be made working without an FPU, and for such applications, we have workable solutions. The second class of applications will not work satisfactory without an FPU anyhow, regardless of whether we have a soft FPU emulation or not.

Originally Posted by gulliver

Of course it will be slower. But it is better to have a slow working program than none at all. That is the point.

Not much of a point, really. The typical applications for which it is acceptable to run slow will typically have a non-FPU version anyhow, and the remaining ones do not make sense to run slow either.

Originally Posted by gulliver

Besides, many FPU less 060s are clocked at 75mhz, so the speed increase can certainly help ease the pain. Also we are no longer stuck with just 90s accelerators, current ones are much faster.

We are not talking about a a factor of 2 (assuming that some 68060 can even go up to 100Mhz), but more likely about a factor of 20 to 1000, depending on what is exactly emulated, and how well the emulation is optimized. Doubling the speed or not does not quite make a difference between "slow" and "slower". For those applications where we do not have non-FPU versions, it is hardly an acceptable speed decrease.

Originally Posted by gulliver

Increasing the list of working programs on Amigas is a plus for any OS.

I cannot really give any numbers, but I would assume that programs that are acceptable to run slow and require a FPU, and no non-FPU version exists are really in the minority.

[Mathesar]

I agree that it makes little sense to develop FPU emulating libraries. Too much work for too little benefit.
It is probably a better idea that developers just use the math libraries instead of selecting "68060" in the compiler settings. A lot of developers are probably not aware of their compiler using the FPU for that few float or doubles they are using in their code. I don't code much for the Amiga but for my work I code a lot of signal processing code for ARM and there I rely a lot on fixed point (thus integer) variables because those run faster, even with an FPU present. Often, the fixed point version is even more precise than single precision float.

And, soft floats work too. On my A3000 I run spice(circuit simulation) and Cinema4d without FPU.

An FPU-less Amiga is really not that bad and an 68LC060 surely beats the 25MHz 68030/68882 combo of the standard 3000

[JimDrew]

Originally Posted by Misclegend

also you can't play clickboom Quake or Duke nukem 3d in Fusion or shapeshifter
thos games requires FPU

FUSION supports using "SoftFPU" to emulate the FPU, and that works with these games.