@umisef

Quote:

And let's be real --- the only reason the 68080 can do that (if it can), is because it is running at 1995 clock rates, but on hardware containing modern day memory blocks.

The reason is that the 68080 is designed like a modern CPU from INTEL or IBM.

The reason that the 68080 runs slow is because its inside an FPGA.
If you put the latest IBM 4 GHz PPC core into an FPGA - then it will run also at clockrate compareable of the 68080.


Umisef, I see a clear difference in our discussion.

When we spoke about about how many cycles a PPC needs for this example..
Then I spoke from experience - as a person that know IBM PowerPC cores by heart,
that are for example used in several so called PowerPC Amigas.

You spoke "fantasy" numbers. You not spoke about any 460 PowerPC or 750 PowerPC and not from 970 PowerPC.

I find it disappointing that you spoke "out of your ass" inventing numbers

@Gunnar

Any plans to to ASIC with the design?

_________________
Doing stupid things for fun...

Karlos Quote:

What was the trade off? I assume they wouldn't have gone from 8 to 4 if it wasn't a trade off against something else bothersome.

The 68060 designers did extensive code analysis and performed cost benefit analysis on all tradeoffs.

The Superscalar Architecture of the MC68060 Quote:

We used dynamic code analysis of existing 68k applications to determine the instruction-fetch bandwidth necessary to support the superscalar operand-execution pipelines. The chip's instruction-set architecture contains 16-bit and larger instructions, with a measured average instruction length of less than 3 bytes. Simulations based on trace data indicate that, holding the rest of the architecture constant, with the combination of a branch-prediction driven prefetch and an instruction buffer, a 64-bit instruction prefetch would be only marginally faster than a 32-bit instruction prefetch. Based on this analysis, the instruction-fetch pipeline interface has separate 32-bit address and data buses. All instruction fetches are 32-bit aligned fetches. The instruction cache supports a continuous one instruction fetch per cycle rate.

Performance is "marginally" affected with only a 4 byte/cycle fetch while instruction fetch can use 1/3 of a small embedded core's power. The 68060 was not too small but it was designed for the embedded market. A higher performance upgrade of the 68060 likely would benefit more from an upgraded instruction fetch size.

average instruction length
PPC 4 bytes/instruction
68k 2.5 - 3.0 bytes/instruction

A PPC CPU core with only a 4 byte/cycle fetch can't even be superscalar (issue more than one instruction/cycle) while the 68060 is comfortably superscalar with the same fetch.

https://old.hotchips.org/wp-content/uploads/hc_archives/hc06/3_Tue/HC6.S8/HC6.8.3.pdf Quote:

45-55% of instructions issued as pairs/triplets (existing 680x0 code) 50-65% of instructions issued as pairs/triplets (targeted 68060 code)

The magic is in the decoupled instruction fetch pipeline (IFP) with instruction buffer that fetches and predecodes instructions when the execution pipelines are stalled or executing multicycle instructions.

@Karlos

Quote:

Any plans to to ASIC with the design?

Yes.


The Apollo Team does follow in our design process a lot what IBM does in CPU development.
Even our in internal register naming policy does strictly follow IBM chip design guidelines.

We develop our core a lot in simulation, running millions of testcase there.
And we use FPGA as development platform.
Both of this is "state of the art" IBM development procedure.

We have the advantage that our "development" cards are affordable in comparison to IBM FPGA cards.
IBM development cards cost usually around $10,000 each.
As our cards are sold very lost cost compared to this ....
This allows Amiga fans to accompany us on our way.
This allows ten thousands of people to use the Cores - which gives us great test coverage.
And it allows people to run Amiga games, demos at great performance - which gives them a lot of fun.
Using our cards people improve GCC for Amiga, create new Software for Amiga, and develop a better new Amiga OS.

And also "final-goal" is the ASIC.
We said this clearly.

@matthey

Quote:

The Superscalar Architecture of the MC68060 Quote:

But do you understand that you quote "a marketing paper" ?
This is sales people "talk" = aka a lie
You need to understand which papers are marketing lies and which are correct true facts.

The original 68060 Hardware developer crew was VERY keen on doubling the fetch to 8 Byte.
And they were this for very good technical reason.

A lot code uses INTs .
And doing simple INT operations like int+= 10
gives you a 6 Byte instruction = ADD.L #10,D0
And the 68060 could in theory do 2 of those instruction per clock cycle.
If it could fetch them ... So there was never a doubt in Motorola development that 4 Byte is a limitation and that 8 Byte would give big improvements.

You know the marketing people will also tell you that smoking is healthy.
And at IBM the marketing people also said that POWER core beat INTEL in integer performance.
While the POWER chip designers would tell you something different.

Last edited by Gunnar on 12-Feb-2024 at 10:20 PM.

@Gunnar

Is there any indication of when?

_________________
Doing stupid things for fun...

@Gunnar

>This allows ten thousands of people to use the Cores - which gives us great test coverage.

Did they sign up as beta testers, or did they expect it to be working perfect as advertised.

This is one of my beef I have with AmigaKit getting pushed updates I never asked for, and having to find out that something broke that might have deleted all my files or corrupted my disk. Let’s say I did not find it particularly funny.

Yeh sure it can be tempting to shorten the beta test period, by pushing things to users, and let users be beta testers. True it speeds up development, but is also not pleasant experience for the users.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Gunnar Quote:

But do you understand that you quote "a marketing paper" ? This is sales people "talk" = aka a lie You need to understand which papers are marketing lies and which are correct true facts.

The chief architect of the 68060 was expected to lie because there was not enough time to upgrade the instruction fetch from 4 bytes/cycle to 8 bytes/cycle. In my experience, core architects can be liars but criminals and especially imposters can be too.

Gunnar Quote:

The original 68060 Hardware developer crew was VERY keen on doubling the fetch to 8 Byte. And they were this for very good technical reason.

Believable. It's probably more fun to work on the higher performance variant of a core than the lower power and more practical base model.

Gunnar Quote:

A lot code uses INTs . And doing simple INT operations like int+= 10 gives you a 6 Byte instruction = ADD.L #10,D0 And the 68060 could in theory do 2 of those instruction per clock cycle. If it could fetch them ... So there was never a doubt in Motorola development that 4 Byte is a limitation and that 8 Byte would give big improvements. You know the marketing people will also tell you that smoking is healthy. And at IBM the marketing people also said that POWER core beat INTEL in integer performance. While the POWER chip designers would tell you something different.

The 68060 can issue a pair of 6 byte instructions like "ADD.L #10,D0" every cycle. The only times it can't are after a pipeline flush or when the instruction buffer is emptied from too many consecutive large instructions. It's easy to see that this is not common even though it hurts to lose any instruction issues due to an empty instruction buffer. The real Gunnar has posted his dislike for the minimalist instruction fetch on the AC forum but it gives good propaganda to make the large instruction fetch of the AC68080 look good. You are correct that architects are sometimes guilty of marketing propaganda.

Last edited by matthey on 13-Feb-2024 at 12:32 AM.

@Gunnar

Quote:

The 68060 was in many ways leading and very advanced at its time.

68060 has inferior FPU which matters for Quake.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Gunnar

Quote:

The APOLLO 68080 can decode up to 4 instructions per cycle. The 68k instructions have variable length... To know where the 4th instruction is in the stream you need to know where the 2nd starts , and based in this you need to have decoded where the 3rd starts ..

That's nearly useless when that statement doesn't show the ALU pipeline count.

AMD K7 has three instructions per cycle that are backed by three IEU and three AGU pipelines. The vector path has its MROM's three decoders. MROM's three decoders and three integer decoders share the same three MacroOps ports. Two IEUs have IMUL functions.

Intel Core 2 has four instructions per cycle that are backed by three IEU** and two AGU pipelines.

Intel Pentium 3 has three instructions per cycle that are backed by two IEU** and two AGU pipelines.

**Shared port with FP and SIMD pipelines.

Pipelines may not be functionally symmetric.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@ppcamiga1

Quote:

ppcamiga1 wrote: @matthey my amiga one work like my amiga 1200 only better bacause 1000 times faster. my amiga one is better amiga than these made by commodore sfter amiga 3000. 68k gives nothing and there are no reason to swithc to it.

Can you run Deluxe Music 2 on your AmigaOne/AmigaOS 4.1 FE?

Without UAE, can you run WHDLoad retro Amiga games on your AmigaOne/AmigaOS 4.1 FE?

Without UAE, can you run retro Shapeshifter on your AmigaOne/AmigaOS 4.1 FE?

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Gunnar

Quote:

Gunnar wrote: @Karlos Quote: how practical is a softcore PPC, one designed specifically for the fundamental limitations of 32-bit addressing and single core? How much work is it? Making an FPGA RISC softcare is a lot easier and a many times less work than making a good CISC core. Making a PPC FPGA would be a magnitude less work than the development of the 68080 needed. How fast would this be? FPGA does significantly limit the clockrate compared to using an ASIC. For example at IBM at the CELL development we put the PPC core of the CELL for testing and debugging in an high end very fast $10.000 FPGA. In the FPGA the PPC core reached 50Mhz ... while in the ASIC it reached over 4000 MHz. Sony sold the PS3 with 3.2 Gigaherz - which was a low value actually for the design. We at IBM ran the CELL ASIC at 4.8 Gigaherz with proper cooling. As you can see there is a big difference between the clockrate the same design gets in an FPGA versus an ASIC. The 68080 reaches about 90-100MHz in consumer FPGA - while in an ASIC the 68080 could easily reach several Gigaherz Lets say your PPC will reach around 100MHz

Without a proper 68K MMU, your AC68080 design is not Linux-qualified.

Linux-qualified is important for general embedded markets.

Motorola's 68060-equipped machine can run 68K Linux distro.

IBM has purchased Red Hat Enterprise Linux (RHEL) for the Linux cred for its POWER series CPUs.

Can the retro Amiga market sustain enough funds for your AC68080 ASIC goals?

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

Quote:

The 68060 can issue a pair of 6 byte instructions like "ADD.L #10,D0" every cycle. The only times it can't are after a pipeline flush or when the instruction buffer is emptied from too many consecutive large instructions

68K instructions have a length between 2 to 22 BYTE each.

1) The 68060 ALUs can execute 2 instructions per cycle.

The 1st ALU has no length limitation and can execute instructions of up to 22 BYTE long.
the 2nd ALU is limited to max 6 BYTE long instructions.

2) The shortest possible bundle of two 68K instructions is 4 Byte long.
3) The Icache of the 68060 can load 4 BYTE instructions per cycle.
= This means the 68060 can execute 2 instructions each cycle as long they are shortest possible bundle.


The 060 has an internal buffer where it can "accumulate" fetched instructions.
This buffer is needed as the icache only loads 4 BYTE and even 1 single instruction can be 22 BYTE long
The 060 needs 6 cycle to accumulate loading such an instruction.

When running the shortest possible bundle of instructions = 4 BYTE
the 68060 ICACHE can load exactly the 4 bytes it uses.
Therefore the 68060 is NOT able to "accumulate" any bytes for executing longer instructions
as long its executing the shortest possible code bundle.

To be able to accumulate more instruction Bytes the 68060 needs to slow down.
By either executing a slow instruction like DIV,
or by not executing pairs of instructions.


The 68060 is a very nice CPU.
Considering in what circumstances it was developed, under time and money limitations,
and under the knowledge that this CPU will be the last of its kind and that the team working on it will have to move to others areas after it.

The decision of MOTOROLA to stop developing 68K CPU was made before the 68060 came out.
You have to imagine this situation.
They people working on the 68060 knew that their CPU has future
and there was for sure also uncertainty of the peoples future in their mind.

Under all this circumstances the 68060 is an impressive CPU.
But the fact that with 8 BYTE fetch the 68060 would be more impressive is just a true fact.



Quote:

The chief architect of the 68060 was expected to lie

Wow! Now you call Joe Circello a liar?

@Hammer

Quote:

t statement doesn't show the ALU pipeline count.

The APOLLO 68080 looks like this.

1) Icache can fetch 16 BYTE per cycle.
These 16 BYTE can span 2 cache rows.
This means the 68080 does NOT need to align loop in memory to have full speed.
The 68080 is the first 68k CPU with this feature.

In parallel to providing instructions to the Decoders
the APOLLO 68080 Icache reload more instructions from memory to Icache.
This is a feature greatly increasing performance.

2) The Decoders can decode up to 4 instructions per cycle.
But frankly 4 instruction in parallel per cycle is an uncommon case.
Normally code runs around 2 instructions per clock.

3) the Apollo 68080 has TWO EA units.
Each EA unit can calculate address of using memory (read/write) and
can execute instructions like LEA, ADDA, SUBA on its own.

4) The DCache can load 8 BYTE of DATA each cycle to the CPU.
The 8 Byte can be of any memory alignment and they can span even 2 Cache lines.
This feature is exceptionally and gives the 68080 great performance in memory operations.

In parallel to doing one READ the DCache can even accept one WRITE to it per cycle
and it can in parallel Reload and Prefetch Data from Memory.
The Apollo 68080 DataCache will watch memory access and can by itself detect streaming access
like memory copies, on detecting such access pattern the DATA Cache will do automatically prefetch memory load. This feature is great. It gives the CPU a huge memory performance.

The IBM 970 PowerPC was the first PPC having the same feature as the APOLLO 68080
All previous PPC can not do this automatic memory prefetching and have because of this a much lower memory performance. This feature makes a bug difference and is the reason why Apollo 68080 at 90MHz can outrun in memory operations a Motorola G4 PPC at 1000MHz running in an AmigaONE.

5) The APOLLO 68080 has 4 ALU Units:
- 64bit AMMX SIMD unit
- FPU
- 2 normal integer ALUs

6) 2 parallel working Bus Memory Controller

The 68080 has 2 independing memory controllers.
The fastmem memory controller supports 64Bit access and support prefetching and bursting.
The 64bit wide memory bus allows the 68080 to reach far better memory performance than any 68K before.

The Apollo 68080 has in addition a second 32bit memory controller which can in parallel operate.

Both controllers can work in parallel without blocking.
The Amiga bus/ Zorro and Chipmemory are connected to the 2nd controller.

This allows the 68080 CPU in an Amiga to e.g. do for example in parallel a write to chipmemory,
while at same time loading more instructions from fastmemory.

The power of two independent memory controllers makes the 68080 extremely powerful in Amigas.

As you will know the Amiga 1000/500/600/2000 mainboards speak 68000 protocol,
while the A1200,A3000,A4000 mainboards speak the differen 68020/30 protocol.

The Motorola 040/060 CPU have another incompatible protocol
This makes using 040 or 060 CPU complicated in Amiga - as you need extra logic to translate the protocols.
This makes 040 and 060 slower in accessing Amigas chipmemory.

The APOLLO 68080 CPU speaks natively both 68000 and 68030 bus protocol.
Thus means you can directly connect it to Amiga mainboards - and not need any translation that would slow down.

@Gunnar

Are there any good example benchmarks for the 68080 versus 68060 using the same object code (i.e. no 68080 additional registers or instructions) that demonstrate the impact of these features? Something that can be shown to be beyond the gains you would get from higher clockspeeds alone, or if possible running at the same clockspeed as the 68060 ?

It would be good to see separate memory-bound and compute-bound examples.

Last edited by Karlos on 13-Feb-2024 at 12:59 PM.
Last edited by Karlos on 13-Feb-2024 at 12:58 PM.

_________________
Doing stupid things for fun...

@Karlos

Hello Karlos,

sure you can use many benchmarks to see this.

Mind that the Apollo 68080 CPU is internally designed as a significant improved 68060.
The Motorola 68060 was good and the Apollo 68080 is an improved evolution of it.


good old Sysinfo is a start
Sysinfo 4.40 running on both 060 and 080 at 90MHz will probably score around
68060 ~ 62
68080 ~ 176

The Apollo 68080 at same clock will score nearly 3 times higher than the Motorola 68060


BUSTEST is excellent to measure memory READ/WRITE and COPY

Here the 68080 will again score many times more than the 060.
Depending on your 060 card this can be in the order of 68080 being x10 times faster
e.g 600 MB/sec versus 50MB/sec


AIBB tests can be very interesting.
AIBB offers very many benchmark and the APOLLO 68080 CPU running at the same clock
will beat the MOTORLA 68060 in each and every test.
And in some test even a factor of being 300% or 500% faster.


I personally like Minibench a lot
because its very detailed measure many aspects of the CPU
and the cache and the memory performance.

In Minibench you can very clearly see in which test the 060 suffers from the ICACHE bottleneck severely.
And you can see in which Tests the Apollo 68080 reaches even an average of 3 or more instructions per cycle.

Minibench also measure memory read and write very nicely and you can here clearly see the technical advantages that the 64bit BUS and the smart Data-cache with prefetcher provide to the Apollo 68080.


The Apollo 68080 CPU is also very popular amound ATARI developer
If you are ATARI fan or user then you will know their most famous benchmark suite "KRONOS"

KRONOS is a very nice benchmark running many detailed CPU, INTEGER/ SHIFT/ MEMOR/ even OPENGL benchmarks ... and of course the Apollo 68080 beats the 68060 in each and every benchmark.
It would be funny if not



That said:

A CPU is many different aspect and can do hundreds of different operations.
Comparing 2 CPUs with just one number makes never any sense!

At the end of the day each routine and algorithm uses different aspect of a CPU.
And you can create were 68080 might nit be able to fully benefit from its enhancements
and both 060 and 080 score the same ...
And their can be algorithms and programs where the improvements that the 68080 catch
and you see a x10 times performance advantage - at the same clock.

@Karlos


A quick example:
This is 68060@50 versus 68080@90 ...
So there are not the same clock !



AIBB is also a very bad test for 68080 :( as many of the advantages of the 68080 like doing up to 4 instructions per clock, not trigger well in this test.

@Gunnar

Quote:

A CPU is many different aspect and can do hundreds of different operations. Comparing 2 CPUs with just one number makes never any sense!

I agree. However it's also very good to be able to put a physical measurement on something in practise (even if not fully representative) rather than arguing over the theory of operation.

Speaking of Atari, don't they also have ColdFire v5 accelerators? Where does the current 68080 sit in relation to those?

_________________
Doing stupid things for fun...

@Karlos

Quote:

Speaking of Atari, don't they also have ColdFire v5 accelerators? Where does the current 68080 sit in relation to those?

Not the V5, The Coldfire V5 CPU does exist but it was only sold to one special project customer.
I have a Coldlfire V4 system and I have both V4 and V5 Developer documentation from Motorola.
The Coldfire 5 developer documentation I got under NDA.

The ATARI have the FIREBEE with uses a Coldfire V4 running at 265 MHz.

The Coldfire V4 has 1 Pipe Only.
It has only 1 EA unit and 1 ALU.
The 68060 in comparison has 2 EA units and 2 ALU.


The Coldfire V4 can in some circumstances do something like "light" Super-Scalar
and can run 1 instruction in the EA Unit (e.g. LEA) and another instruction in the ALU (assuming it not needs the EA unit this turn)

This is by for not as good as the Super-Scalar of the 68060
and far from the power of the Apollo 68080 - which can schedule up to 4 instructions.
But its better than nothing.

The Coldfire has some drawbacks
- it can often not do BYTE and WORD operations.
- its EA modes are limited
- it lost a number of instructions, even very good ones
- its limited to 6byte instructions.

This means Coldfire can NOT really run old code.
Ideally you want to recompile all your programs.

If you run KRONOS test then APOLLO 68080 does generally beat the Coldfire in most tests - even if the Coldfire is clocked nearly 3 times higher - and with the Coldfire running the Coldfire tuned benchmark code.

Clock by Clock the Coldfire V4 is slower than an 68060.
And the APOLLO 68080 being a much improved 68060 design can stand its ground against the Coldfire.

Why bother with FPA? When a fast cpu can do the job and cheaper? Plus you can run multi oses at the same time. Plus If what you can set the host system to boot straight in to emulator. Another plus their no waiting for some to make the hardware. heck even a pi 4 runs faster than a vampire. For example my rysen 3900 runs even mac ppc code faster then the old power mac I used to own. You be better off making full os4 emulator because if that what you want you can get it for less money and less time. UAE is already their for 68k. Plus the next rysen may get a 40 percent speed boost over last gen. If you want a small computer you can easy get almost anything in a 4 by 4 by 2 form factor. You demanding custom hardware that will never come out is not the solution