Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Performance and Benchmark Results!

3D Bench Markpage  1 2 

Gunnar von Boehn
(Apollo Team Member)
Posts 6207
02 Jul 2016 08:51


Thierry Atheist wrote:

The 68060 FPU has an external math library, as at the time they couldn't fit all of the FPU math functions into the 68060 when it was originally made back in the 1990's.
 

To be precise the story was the following:

When doing the transition from the 68040 to 68060, the 68K instructions were reviewed and Motorola. And Motorola decided to clean up a little and to remove some by their opinion very rarely used instructions.

The thinking behind this is, as it not that bad.
Why should you spend resources on something which is never used?

The removed instruction where some MULTIPLICATION, some DIVIDE, some special instruction originally designed for communication with 8bit custom chips, some special Compare, Special Exception, and Special multi CPU Sync instruction.

Removing those instruction was not without drawbacks.
For example the MUL and DIV were actually used pretty often and removing them gave a noticeable performance hit for some software.

Also these missing instructions needed to be provided by trapping and calling a software library - which was slower and with required the library to be there. When calling a program from Workbench these library was always there - but when booting the AMIGA from floppy - this was not the case.
So this instruction change on the 68060 could give  of course some problems with Demos / Games from floppy.

Nevertheless the 68060 is a good CPU.
But we have to acknowledge that in some areas the 68040 had an advantage over it.

The story with the FPU is slightly different.

The 68881/2 FPU was originally a separate chip.
This means communication with it took some cycles.
While an internal CPU instruction in the 68020/68030 could be as fast as costing only 2 clocks - the FPU instructions always took longer. So taking many cycles per FPU instruction was just normal.

The FPU supported the basic instructions like FADD, FSUB, FMUL which in fact are the very most often used FPU instructions.
The FPU also provides some form of FPU-function like SINUS which in fact were instructions which inside the FPU were provided by having something like a subroutine which ran hundreds of cycle to calculate the result.

Now when the 68040 was designed the FPU was brought into the CPU internally - which removed the big communication time between these chips.
This did speed up the basic instruction like FADD, FSUB by a huge amount. The 68040 FPU is over 10 times faster than an 68881.

Now the FPU subroutines like SINUS would still need a subroutine inside the chip for this to be called.
Now Motorola could decide whether doing this inside a microcode ROM - or doing the same function in software instead.

The microcode ROM has a number of HUGE disadvantages.
A function like SINUS taking hundreds of cycles - would mean that the CPU has super long lasting instructions.
Long lasting instruction are VERY bad for interrupt response time.

Like for example in the AMIGA the serial interface does throw an interrupt for every received byte - for good device speed you want a CPU which has not super-slow instructions and can respond very quickly.

Motorola decided to improve this by doing the SINUS in software - which allowed to get easier a great interrupt response speed.


Thierry Atheist

Posts 644
02 Jul 2016 09:14


Hi Gunnar, thank you for the very detailed response.

What is the Apollo Core's Team decision about how to handle this?

Is it still being decided upon, or are you doing something that you would rather not publicly disclose?

I mean, if you want not to discuss it doesn't make a difference to me in how much I want to get a Vampire ][, I was just hoping that maybe, NOT having it external, we could get still more improvement by placing it inside the FPGA.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
02 Jul 2016 09:45


Thierry Atheist wrote:

What is the Apollo Core's Team decision about how to handle this?

If you compare 68040 and 68060 then you see that

68040 did offer 100% of instruction and could do up to 1 instruction per clock.

68060 did offer only 90% of instruction but could do up to 2 instructions per clock.

Apollo/68080 offers 100% of instructions and can do up to 4 instructions per cycle peak. With 2 instructions per cycle most of the time.


Roman S.

Posts 149
02 Jul 2016 14:14


And how it will handle SINUS and others? Same like the FPU in 68040?


Keith Beard

Posts 22
03 Jul 2016 11:42


Gunnar von Boehn wrote:

Keith Beard wrote:

  I think this will be worked on very soon, the guys are refining the integer core and trapping errant instructions for additional compatibility.
 

 
  All instructions of the 68040 are supported on APOLLO 68080.
  This means APOLLO does not need to trap like the 68060 needs :)

I meant it as the team were trapping instructions (i.e. with Fusion) - I should of been clear to mention that there was no CPU error / opticode trapping.

Sorry about any confusion =)

posts 25page  1 2