A longer latency might be less a problem provided the throughput remains high, i.e. one could address this by a secondary FP ALU which could absorb a second FPU mul/add instruction. Similarly, such a secondary ALU could handle SIMD instructions and double the throughput.

So long,
Thomas

You can run old kickstarts.

But you can't run old Kickstarts together with new games using the FPU stuff. But would this a problem?

Thomas Richter wrote:

A longer latency might be less a problem provided the throughput remains high, i.e. one could address this by a secondary FP ALU which could absorb a second FPU mul/add instruction. Similarly, such a secondary ALU could handle SIMD instructions and double the throughput.

How do you mean this?

The throughput is already high.
The FPU does not stop it runs in fully pipelined.

As you know for a 4x4 Matrix Mul you need, about this:
MUL MUL MUL MUL ADD ADD ADD MOVE
MUL MUL MUL MUL ADD ADD ADD MOVE
MUL MUL MUL MUL ADD ADD ADD MOVE
MUL MUL MUL MUL ADD ADD ADD MOVE

You can execute the Muls easily as they are independant,
but the Adds becomes a problem as they depend on the muls to be finished and the later adds depend on the previous adds to be finished.

Do you see a trick to do the Matrix mul "bubble free"?

SIMD does not solve this issue as SIMD will alos have a latency and with such depending constructs the SIMD unit will also have to wait and stall.

Regarding SIMD, How wide (in bits) would you make the SIMD unit?

Two answers for this: First of all, as far as I know my fellow Amiga users, it wouldn't stop them from trying, regardless of what the manual says, and having the option to *avoid* something breaking, we should rather take this option.

Second answer is a "war time story": Versions of win2000 did not save and restore the SSE registers without proper patches installed, and this means that for some of my "professional products", usage of such extensions had to be simply disabled because customers did not understand or did not want to install official MS patches. Thus, creating additional registers without having a stable Os platform to use them is asking for trouble. It basically means that I cannot use the registers in professional software that should run stably.

I come back to you concerning the matrix multiplication.

Greetings,
Thomas

Isn't rewriting parts of the OS unavoidable?
There must be a lot additional data to be stored from the Superaga, 3d core, bopper and multiple 050/070 processors.
Multiple 050/070's could/should reduce the need for extra registers.

   .loop
   fmove.d (a0)+,fp0 ; fused (4 bytes)
   fmul.d #A11,fp0 ;1  (12 bytes)
   fmove.d (a0)+,fp1 ; fused  
   fmul.d #A21,fp1 ;2
   fmove.d (a0)+,fp2 ; fused (4 bytes)
   fmul.d #A31,fp2 ;3  (12 bytes)
   fmove.d (a0)+,fp3 ;
   fmul.d #A41,fp3 ;4
   fmove.d (a0),fp4 ;
   fmul.d #A42,fp4 ;5
   fmove.d -(a0),fp5 ;
   fmul.d #A32,fp5 ;6
   fmove.d -(a0),fp6 ;
   fmul.d #A22,fp6 ;7
   fmove.d -(a0),fp7 ;
   fmul.d #A21,fp7 ;8
   

With my optimalizations from the 80'ies I let the N050 run at 400mhz. compared to the Compiled code wich will run at 100mhz.

And it has been talked about literaly for years already here about adding or not adding a VPU. ;)

16 muls 10 adds in 40 cycles.
Including 4 doubles(32bytes) to read and 4 doubles to write.

On the N070 it would probobly run at 20-30 cycles.

With A VPU unit we need a bus. Pushing and pulling data out of the unit will steal cycles. When a 64bit FPU has 8 cycle latency, a vpu unit  that performs a 4x4 matrix muls will have more.  To make it run in paralell we need to add alot of logic. (expensive)
If the VPU is located outside the FPGA datatransfer will be slow..

Perhaps 8 cycles to read and 8 cycles to write? and 16 cycles to perform the operation?

Adding another pipeline in the N070 would be bether.. 2 memreads per clock from the datacache will speedup things alot..

I'm just a software guy, so the hardware guys will probobly correct me :D

Take a look at my second optimalization. Here the constant matrix is multiplied with 100 000 cordinates. Then its swapped with SMC. And performs 100 000 more multiplications. Losing the content of a ICache line is no problem. When I only create a new loop for every 3 200 000 cycles.. What I am asking for is to get a cachesnooper that can fix the smc in 50-1000 cycles... If not I will just implement the innerloop in different memory locations.

You can call SMC dirty and outdated but it can double the speed of you chip with proper programming.

I have removed the latency problem in a matrix muls on a cpu that has 8 registers, 8 cycle latency on muls and add. I can do this because the instruction cache is fetching data in paralell with the datacache.

By using Self modified code, I push this 100mhz CPU to its limits.
I have turned the 100mhz FPGA to a 400 MHZ FPGA.

And didn't write paralell.for() with 8 cores :D

The stoneage teqniques still work.

Anyway - other optimizations CPU core for DSP style work make only sense if it's not costly. What is important for main CPU is to handle efficiently code with lots of branching and unpredictable paths.

The proper solution would be DSP like coprocessor, ultrasimple and optimized for repetitive calculations with little branching, and with high power to cost ratio, possibly replicating it.

It is an inappropriate solution for the design.

Fast programs are fast because the algorithm is fast. Not because someone wrote self-modifying code.