68k
  move.l x,d1
  muls.l y,d0:d1
  lsl.l #4,d0
  clr.w d1
  rol.l #4,d1
  or.w d1,d0   ; return d0
(a faster one can be done, but you will lose accuracy)
x86
  mov eax, x
  imul y
  shrd eax, edx, 28  ; return eax

Note that for me, the fact shrd is fast or not on x86 today is irrelevant.
What's relevant is the speed we can get out of the 680x0.
And this kind of instruction seems useful for that, provided it's faster than the above 68k code.

What do people here think about it ?

Well two stages consistent of 1 full arithmatic stage and two half logic stages prior to and after the arithmatic stage, but like i said silly idea.

    68k
     move.l x,d1
     muls.l y,d0:d1
     lsl.l #4,d0
     clr.w d1
     rol.l #4,d1
     or.w d1,d0   ; return d0
    (a faster one can be done, but you will lose accuracy) 
    

3 cycles are used in the muls. and 2 to convert..
 

     move.l x,d1    ;1 p1 fused
     muls.l y,d0:d1 ;2 p1-p2
     lsl.l  #4,d0   ;4 p1
     clr.w  d1      ;4 p2 
     rol.l  #4,d1   ;5 p1
     or.w   d1,d0   ;5 p2 forwarded
   

I also think this is very good. The N050/N070 is very impressive when you think about that this is a hobby project you guys do in your spare time after work. I think that it will be fast enough to decode MP3 and play youtube movies, render web pages. etc.

Thomas Richter...

You believe that assembly coders are obsolete, and that a good compiler always will beat handmade code. Why don't you provide me with some important sourcecode you want me to implement fast.
I always beat the compiler when I code Mc680x0 assembly.
Because I count cycles...

     68k
      move.l x,d1
      muls.l y,d0:d1
      lsl.l #4,d0
      clr.w d1
      rol.l #4,d1
      or.w d1,d0   ; return d0
     (a faster one can be done, but you will lose accuracy) 
     

      move.l x,d1    ;1 p1 fused
      muls.l y,d0:d1 ;2 p1-p2
      lsl.l  #4,d0   ;4 p1
      clr.w  d1      ;4 p2 
      rol.l  #4,d1   ;5 p1
      or.w   d1,d0   ;5 p2 forwarded Does not work
    

To prevent any misunderstanding.
The Forwarding has a precondition.
Forwarding between the pipes is only possible if only 1 Pipe does an ALU operation. This means you can forward between 1 MOVE and 1 OPERATION - but not between 2 OPERATIONS.

Does this make sense?

Basically, filters can implemented by "lifting". An elementary "lifting step" is a addition, a multiplication, a shift and an addition:

(((a+b)*c + d) >> e) + f -> g

as many of these steps as possible should be fused in the CPU to make such common algorithms fast. For example the multply-shift step, or the multiply-shift-add step if possible. The addition of "d" is just rounding (thus, d is typically (1 << e) >> 1).

So long,
Thomas

Gunnar von Boehn wrote:

Or would it make sense to use a FPU for this?   How sensible would be using the FPU be if your FMUL needs 1 cycle?

The mul itself is not the whole story. It is a multiply-add that is the important step. The mul+shift is just a fixpoint implementation of a multiplication.

Gunnar von Boehn wrote:

B) Even the most optimal SHRD without any Microcode, needs 2 Register write-ports. This means it would count like 2 instructions.     C) You used 4 68k-instructions to implement "SHRD".   The 4 instructions would take 2 cycles on the 070.   Is 2 Cycles a problem?

Not even 100 cycles would be a "problem". (-; The point is: Make it as fast as you can, because this is a "heavy duty" operation that appears in all common signal processing algorithms. Other heavy duty operations are (surprisingly) round to integer - thus a separate rounding mode specification in fmove.l fpx,dx would be very helpful here as well. This is the core of any quantization algorithm, the heart of all lossy coding algorithms.

Gunnar von Boehn wrote:

D) Using Bitfield you can do the same in 3 instructions.   So its just 1 instruction more than the SHRD - is this a problem?

Bitfields used to be slow, and they are not exactly what is needed here.

Gunnar von Boehn wrote:

E) Assuming that we wanted to add SHRD to 68K.   What encoding would you propose?

I would rather use a coprocessor encoding for all signal-processing type instructions, probably leaving the option of "vectorizing" these instructions later. That is, multiply+add, vector+add, vector round to int: That might go into a separate coprocessor slot.

Line A is somewhat used up because old Mac-Os has its Os-calls in there, and Shapeshifter should probably continue to work.

Greetings,
Thomas

Can you explain what is needed here?

The example that was used does this:
Out[31 to 0] = In[59 to 27]

So what is it : Is it a SHIFT that we need or a BITFIELD-EXT?
Or could eather both do the job?

In this example we needed 64 source but only one 32bit result was used.
This means the instruction needed only to update 1 32bit destination.
Whether the instruction has to update 1 or 2 destinations makes a big difference.

Which form do we actually need?
In this example only 1 destination was needed - is this always the case - or was this an exception?

     8:56 (0xIIFFFFFF ffffffff)
     
     d0:
     0xIIFFFFFF
     
     D1:
     0xffffffff
     
     your code convert to this:
     
     d0:
     0xIFFFFFFf
    

In the x86 version the High longword is ignored.

  8:56 (0xIIFFFFFF ffffffff) >> 28
   (0x0000000I IFFFFFF f)

      move.l  x,d1    ;1 P1 fused
      asr.l   #2,d1   ;1 P1
      move.l  y,d2    ;2 P2 fused
      asr.l   #2,d2   ;2 P2
      muls.l  d2,d0:d1 ;3 (P1/P2) (return d0)
      

      move.l  x,d1    ;1 P1 fused
      asr.l   #1,d1   ;1 P1
      move.l  y,d2    ;2 P2 fused
      asr.l   #1,d2   ;2 P2
      muls.l  d2,d0:d1 ;3 (P1/P2) (return d0)
      

But my bits are the most insignificant. So accurancy will be improved alot.

  N68k
   move.l x,d1
   muls.l y,d0:d1
   bfextu d1{0,4},d1
   lsl.l #4,d0
   or.l d1,d0   ; return d0
  x86
  ; Shuffle some registers since registers not general purpose!
   mov eax, x
   imul y
   shrd eax, edx, 28  ;shrd=slow, return eax
  ; Shuffle some registers since registers not general purpose!
  

There I fixed it! Hmmm, I don't see any x86 advantage now ;).

  move.l  x,d1    ;1 P1 fused      
  asr.l   #2,d1   ;1 P1      
  move.l  y,d2    ;1 P2 fused      
  asr.l   #2,d2   ;1 P2      
  muls.l  d2,d0:d1 ;2 (P1/P2) (return d0)
  

       mov  eax, x       ;1   (free)
       imul y            ;10 
       shrd eax, edx, 28 ;12
    

       mov  eax, x       ;1 (free)
       imul y            ;18
       shrd eax, edx, 28 ;9
    

       mov  eax, x       ;1 (free)
       imul y            ;5
       shrd eax, edx, 28 ;3
    

My post was meant as a joke. The original shorted the 68k in regard to data movement. It is more efficient to do the shifts before the multiply if all that is needed is d0. I wonder if a mulhs.l d2,d0 (mul high signed) could be made faster than muls.l d2,d0:d1. It would keep from trashing a register even if it wasn't faster and it's not unusual that just the upper 32 bits are used. A combination multiply shift as ThoR suggested would also be nice but it would require a 64 bit shift and write 2 registers.

What happend again when you do this:
muls.l d2,d0:d0

When both targets are the same?

        mov  eax, x       ;1   (free)       
        imul y            ;8        
        shrd eax, edx, 28 ;2
        

  http://www.gmplib.org/~tege/x86-timing.pdf
 

   N68k
    move.l x,d1
    muls.l y,d0:d1
    bfextu d1{0,4},d1
    lsl.l #4,d0
    or.l d1,d0   ; return d0
  
   x86
   ; Shuffle some registers since registers not general purpose!
    mov eax, x
    imul y
    shrd eax, edx, 28  ;shrd=slow, return eax
   ; Shuffle some registers since registers not general purpose!
   

; assumes esi/ebp (or any two register) are used as 32 bit registers earlier.
; 32 bit operations are zero-extend to 64 bit for free.
imul rsi, rbp ; any registers. 64*64->64 bit multiply
shr rsi, 28  ; any register

Which for my processor have a latency of 4 (3+1) and throughput of 1.
(I did see your smiley ;)