To prevent misunderstandings.
OOO does not influence the max peak speed.

Apollo can issue max 4 instructions per cycle,
if running at 100MHz this would be peak 400 Mips.

But like with a car which might have a peak speed of 150 miles per hour, not all street allow you to run this.

The APOLLO pipeline actually is designed to perform very good already even without OOO. In contrast to PPC for example.
OOO can accelerate code which suffers from Latency stalls.

The biggest gain for OOO on Apollo are FPU instructions as many they have higher latency. e.g 6 cycle
And also on routines having high percentage of cache misses.

In total OOO might give an average boost of around 10%

Our goal is to create the "ultimate" 68K.
Which can play in the same ballpark as the modern chips of the big companies.

We cherry picked the best tricks of the big ones and added them to APOLLO. Clock by clock APOLLO already performs very good.
Clock be clock Apollo smokes already many PPC and all ARM chips.
Frankly Haswell is a great core - we will not beat it.

We have a roadmap of more improvement coming in the next time.

The uneven 68k processors are just minor updates to the preceding even ones (000 and 010, 020 and 030). I think ooo would be significant enough to justify a whole generation step and thus we should proceed from the 68080 ("oh-eighty") to the 680A0 ("oh-A-ty")... :)

ASIC is probably in the half million Euro  / dollar and upwards ballpark.
Even given the success of several recent kickstarters, half or even as much as 1 million euro required would be tough to do that way, relying fully on the rtetro-community.. (You'd probably need some manufacturer on board that plans to use it for something else..)

Salteadorneo salteador wrote:

Congratulations.   Do you want to add an SPU-style unit?   And add more cores? This I guess it would be for an ASIC version.

Our current FPGAs seems to fit one core only. To be multicored, we dont need just "space", core needs to be 100% done.

Beside no AmigaOS scheduler (or MacOS Classic, Atari ...) is far more problematic. AROS backport of x64 SMP and Gallium may be the high tide, when its on the to do list. And that would enable what you desire.

Until then, its far better to push the features and clock speed ahead.

Funding a full system would definitely be a more compelling offering in terms of crowdfunding. Look at the AtariVCS campaign as an example.

The other question is whether or not Gunnar and team have an interest in pursuing this option or licensing the IP for this purpose.

The Motorola 68060 is the 2nd fastest 68K CPU.
If you compare both Apollo 68080 and the M68060 you can clearly see the difference those improvements make.

 
Doing an ASIC needs a lot of preparation time and a big investment.
And then an ASIC is a one time shot.
 
Right now we use FPGAs for the Vampire cards.
The FPGA allow "upgrading" the core version.
So far the Vampire users got regularly a new CPU version which always was improved. We continuously develop the core and continously Apollo gets faster and more powerful.
 
We have a good list of development ideas for the future.
The new Out Of Order features gives a big speed boost for some applications - we saw benefit of up to +40% for some cases.
 

Fully, understood. +10-40% FPU perf. and lowerlatency for V2 and V4, and we will see what V6+ brings :-)

That is likely to be half of real asic/motherboard costs, just because of ...

Technically it is possible I suppose, but reasonable ...

let it develop fully for a year or two before that.

back to topic, OO ex seems to be the feature of P6+ class cpus, but is also connected to this stupid spectre leak. Will we try to avoid that fuss and not to loose performance, I highly doubt someone is gonna use a hardware hack on Vampires :-)

  ADD.L D1,(A0)+

  LOAD  (a0),R2
  ADD   D1,R2
  STORE R2,(A0)
  UPDATE A0+

LOAD  (a0),R2    -- 1 clock
                  -- 3 clock load usage bubble
ADD   D1,R2      -- 1 clock
STORE R2,(A0)    -- 1 clock
UPDATE A0+       -- 1 clock

And if you run such operation in a LOOP then the decoder will but this operations several times in the execution - like this:
 
 

LOAD  (a0),R2    -- 1 clock
                  -- 3 clock load usage bubble
ADD   D1,R2      -- 1 clock
STORE R2,(A0)    -- 1 clock
UPDATE A0+       -- 1 clock
  
LOAD  (a0),R2    -- 1 clock
                  -- 3 clock load usage bubble
ADD   D1,R2      -- 1 clock
STORE R2,(A0)    -- 1 clock
UPDATE A0+       -- 1 clock

The 68k on the other hand does by design not have this problems.
 

68060 @ 50 MHz
FDIV.S  (A0),FPn  ==  0.6

Vampire x11
FDIV.S  (A0),FPn  ==  69.1

= more than 100 times faster than 68060 @ 50 Mhz
= Speed of 68060 @ over 5 Gigaherz
 

On APOLLO you can reach the FDIV performance of a 68060 running with several Gigaherz Clock.