There are places where SMC looks like the simple solution but it's not as simple as it appears. I don't ever use it. Flushing the appropriate caches after SMC is supported of course. I also have no problem with methods that make this more efficient if it can be done in a way that will be compatible in the future.

S P wrote:

In my next proposal I put the constant matrix inside the code in advance. This is very clever because it frees registers, It enables the instruction cache to fetch matrix entries in paralell with the datacache. By using this teqnique a matrix transformation will be almost as fast as copying memory. (Removing the need for an external VPU unit)

I believe the same advantage can be achieved with more registers, another EA, code fusion, and possibly another fpu ALU. This would speed up the chip for all processing without the need and overhead of using SMC.

S P wrote:

Now I propose another optimalization:         In many matrixes you have 0 values and 1 values. With my SMC generated innerloops I can remove instructions that multiply with zero. I can remove instructions that multiply with 1.

Multiply is not a bottleneck. Multiplication is faster than a branch and removing multiplications requires a branch. There is some benefit in removing multiplications in advance in some cases but it is likely more overall work.

S P wrote:

Do you understand the difference?     If I generate 10 innerloops with the size 200 bytes for each frame.     I need to flush 2000 bytes.. This doesn't take long time.         With 100 000 cordinates in the 3d scene  I save 100 000 * 10 * 32 cycles.     If the natami has a cachesnoper that does this job for me in paralell, then I don't need the cacheclear..     The logic I want is simple.. If the the datacache is trying to write to instructioncache then remove the instruction cache line...

Cache snooping would be nice for backward compatibility and safety as well. However, I don't like the idea of guaranteeing and relying on it to for the future. The caches are complicated enough already and messing around near the code being executed is tricky and could change with a different CPU.

No one is attacking you or singling you out. Everyone here has the same goal so we are all on the same side. We just have different opinions of how to accomplish the goal. Please focus on how you want to see this goal accomplished.

 
    move.l (a0)+,d0  ;1 P1
    muls.l #xxx,d0:d0 ;1 P1
    move.l (a1)+,d1  ;1 P2
    muls.l #xxx,d1:d1 ;1 P1
   

    move.l (a0)+,d0  ;1 P1
    muls.l #0,d0:d0 ;1 P1
    move.l (a1)+,d1  ;1 P2
    muls.l #0,d1:d1 ;1 P1
    ..
    add.l d0,d1 ;2
   

What do you think how good can we get without changing the 68k ABI and without using selfmodifying code?

S P wrote:

fmove.d (a0)+,fp0 ;  fused (4 bytes)     fmul.d  #A11,fp0 ;1  (12 bytes)     fmove.d (a0)+,fp1 ;  fused      fmul.d  #A21,fp1 ;2

The 68K FPU can also use Data-Registers as source.
The typical Matrix Mul will operate on SINGLE size float data.
We can hold 8 single in the data registers.

How much would this in your opinion help us to tune the code without using SMC?

Cheers

Well why should they?
Single precision is more than enough for games.

And that certain architectures like Cell == PS3,
are quite slow in doubles indicates that games won't use them.

  then these would be the same cycles?...
 
    fmul.s d0,fp0
    fmul.s fp1,fp0
 
  Loading a long fp.s value in a data register would be 6 bytes compared to loading a fp.s value in a floating point register being 8 bytes. That wouldn't be so bad as integer registers are easier to save and restore but efficient fpu code would look much different. If 1/2 IEEE fp was supported, a fp.h value could be loaded as a word in a data register taking 4 bytes compared to 6 in a fp register. I would still like to see the 1/2 IEEE fp conversion only (no calculation). Not only does it reduce code size but it's THE best format for a Z buffer. Integer Z buffers are not linear and values outside of the min and max rap around causing very undesirable affects. The min and max can be checked but then it's faster to use floating point. The Z buffer is read and written manually by the CPU for certain effects by the way. A 24 bit integer Z buffer doesn't work so well in the 68k EA just like 24 bit chunky and 16 bit fp.h saves memory too.
 
 

Gunnar von Boehn wrote:

How much would this in your opinion help us to tune the code without using SMC?

 
  Yes, the fpu needs to be tuned without SMC because it will be used from shared drivers (libraries) and compilers may have trouble generating optimal code for SMC. I like your thinking, let's see what others think.

Single precision should be absolutely sufficient for most game engines, I agree. Of course, it requires better compilers than the ones we have now. Due to type promotion in C, computations usually give double results unless you are careful. For example "x * 0.3" is a double even if x is a float, instead you need to write "x * 0.3f" for this, and I believe the compiler is not even allowed to replace the former by the latter, even if the result is assigned back to a float because the result can be different due to different roundings (0.3 is not exactly representable as floating point number, thus 0.3 != 0.3f). Thus, programmers must be careful.

Greetings,
Thomas

Actually we can pass both DATA and ADDRESS registers to the FPU.
This can gives us up to 15 extra single registers...
But code using the ADDRESS registers as FPU registers will not work on legacy 68k classics CPUs.

Then we could check three conditions in one bitmask operation, if none of the bits in imm are set in the src (Z true), if at least one of the bits in the imm are set in src (Z false, X false) or if all the imm bits are set in the src (Z false, X true).

However, i do not know if the internals can easily permit using #n as destination. BTST does that but it doesn't write data ; allowing immediates for writes may well pose a few problems.

Now, apart for AND, are there examples where it could directly work and be useful ?
OR is indeed not of much use.