The CRC algortihm is defined.
To be able to check CRC on Ethernet packets or CRC on ZIPS
you need to implement a compatible algorithms.

S P wrote:

To optimize the slow CRC:   Instead of using a lookup on each byte, you can expand the tablesize to lookup two bytes in one lookuptable 2^16*4 = 256KB.   With a 256KB table you can halve the number of cycles needed, at a cost of more cachemisses. (256KB is still small enough to fit in a cache)

No 256KB is too big to cache.
This "optimization" will slow the whole down a lot.

Depends on the CPU and memory speed.

On Mc68000-Mc68030 it would probobly be a good Idea.

How many cycles is a cacheline read on the Natami?

I do not think that the 256 Entry Lookup Table is the bootleneck.
The 68070 would technically allow you to do 2 reads per cycle ...

This can be rewritten again remove the ALU stall..

.loop4

move.b (a0)+,d1
move.b (a0)+,d2
move.b (a0)+,d3
move.b (a0)+,d4

eor.l (a1,d1.w),d0
eor.l (a1,d2.w),d0
eor.l (a1,d3.w),d0
eor.l (a1,d4.w),d0

subq.l #1,d7
bne.b .loop4

Timing assuming 68050+no cache misses, move x, reg; op y, reg considered fused in all cases.
----
.next64
  move.l (a0)+, d0      ; 1 fused
  eor.l  d1, d0          ; 1 
  move.l d0, d1          ; 2 fused
  and.l  #$ff, d1        ; 2 
  move.l d0, d2          ; 3 fused
  lsr.l  #8, d2          ; 3
  and.l  #$ff, d2        ; 4
  move.l tab88(d1*4), d1 ; 5 no stall
  lsr.l #16, d0          ; 6
  move.l d0, d3          ; 7 fused
  and.l #$ff, d3        ; 7
  lsr.l #8, d0          ; 8
  and.l #$ff, d0        ; 9
  move.l tab80(d2*4), d2 ; 10 no stall/fused
  eor.l d1, d2          ; 10
  move.l tab72(d3*4), d1 ; 11 no stall/fused
  eor.l  d2, d1          ; 11
  move.l tab64(d0*4), d2 ; 12 no stall/fused
  eor.l  d1, d2          ; 12
  move.l (a0)+, d0      ; 13
  move.l d0, d1          ; 14 fused
  and.l  #$ff, d1        ; 14
  lsr.l #8, d0          ; 15
  move.l d0, d3          ; 16
  and.l #$ff, d3        ; 16
  lsr.l #8, d0          ; 17
  move.l d0, d6          ; 18 fused
  and.l #$ff, d6        ; 18
  lsr.l #8, d0          ; 19 (no and required)
  move.l tab56(d1*4), d4 ; 20 no stall/fused
  eor.l d2, d4          ; 20
  move.l tab48(d3*4), d5 ; 21 no stall/fused
  eor.l d4, d5          ; 21
  move.l tab40(d6*4), d4 ; 22 no stall/fused
  eor.l d5, d4          ; 22
  move.l tab32(d0*4), d4 ; 23 no stall/fused
  eor.l d4, d1          ; 23
  dbra d7, .next64

    bra.b .enter
.loop4
    move.l (a1,d4.w*4),d0 ;17
    eor.l   d5,d0  ;17
.enter
    move.b (a0)+,d1 ;1
    eor.b d0,d1  ;2
    move.b (a0)+,d2 ;3
    lsr.l   #8,d0  ;4
    
    move.l (a1,d1.w*4),d5 ;5
    eor.l   d0,d5    ;5
    eor.b d5,d2  ;6
    
    move.b (a0)+,d3 ;7
    lsr.l   #8,d5  ;8
    
    move.l (a1,d2.w*4),d0 ;9
    eor.l   d5,d0  ;9
    
    eor.b d0,d3  ;11
    move.b (a0)+,d4 ;10
    lsr.l   #8,d0  ;12
    move.l (a1,d3.w*4),d5 ;13
    eor.l   d0,d5  ;13
    
    eor.b d5,d4  ;14
    lsr.l   #8,d5  ;15
    
    subq.l #1,d7  ;16
    bne.b .loop4
  

    

lsr.w  #8, d2        ; 3
and.l  #$ff, d2        ; 4 (remove)

same here:

lsr.w #8, d0          ; 8
and.l #$ff, d0        ; 9 (remove)

This will save 2 cycles. I think 2 more ands can be removed farther down in the code too..

   ------------------------------------------------------------
   
    
   .loop32 
   
     move.l (a0)+, d0      ; 1 fused
     eor.l  d4, d0         ; 1  
   
     move.l d0,d1          ; 2 fused
     and.l  #$00ff00ff,d1  ; 2 
   
     move.l d0,d2          ; 3 fused
     and.l  #$ff00ff00,d2  ; 3
   
     lsr.l  #8,d2          ; 4
   
     move.l tab88(a0,d1.w*4),d3 ; 5 fused
     eor.l  d4, d3              ; 5
   
     swap   d1                  ; 6
   
     move.l tab80(a1,d2.w*4),d4 ; 7 fused
     eor.l  d3, d4              ; 7
   
     swap   d2                  ; 8
   
     move.l tab72(a2,d1.w*4),d3 ; 9 fused
     eor.l  d4, d3              ; 9
   
     move.l tab80(a3,d2.w*4),d4 ; 10 fused
     eor.l  d3, d4              ; 10
   
     (...)
   
     subq.l #1,d7       ; 11
     bne.b .loop32
   
   

On N68k, these can also be...

  mvz.b d0,d1

It would only be 1 word instead of 3 on N68k. It's 4 words on 68k which is a pretty nice size optimization. Of course, SP's suggestion may make this unnecessary.

S P wrote:

move.l d0,d1          ; 2 fused       and.l  #$00ff00ff,d1  ; 2           move.l d0,d2          ; 3 fused       and.l  #$ff00ff00,d2  ; 3

Yea, that's a good trick. I've used it to average the color values of 2 consecutive 16 bit pixels for scaling (creation of mipmaps). It makes a huge difference in performance on the 68060 where using long values can be twice as fast.

    ------------------------------------------------------------
    
     
    .loop32 
    
      move.l (a0)+, d0      ; 1 fused
      eor.l  d4, d0         ; 1  
    
      move.l d0,d1          ; 2 fused
      and.l  #$00ff00ff,d1  ; 2 
    
      move.l d0,d2          ; 3 fused
      and.l  #$ff00ff00,d2  ; 3
    
      lsr.l  #8,d2          ; 4
    
      move.l tab88(a0,d1.w*4),d3 ; 5 fused
      eor.l  d4, d3              ; 5
    
      swap   d1                  ; 6
    
      move.l tab80(a1,d2.w*4),d4 ; 7 fused
      eor.l  d3, d4              ; 7
    
      swap   d2                  ; 8
    
      move.l tab72(a2,d1.w*4),d3 ; 9 fused
      eor.l  d4, d3              ; 9
    
      move.l tab80(a3,d2.w*4),d4 ; 10 fused ! STALL, d2 changed less than 2 clocks ago
      eor.l  d3, d4              ; 10
    
      (...)
    
      subq.l #1,d7       ; 11
      bne.b .loop32
    
    

(My optimizations was just to try avoid address generation stalls and allow as much fused execution as possible)

         bra.b .enter
    .loop32
          move.l (a4,d2.w*4),d4 ; 11
          eor.l  d3, d4              ; 11
    .enter
          move.l (a0)+, d0      ; 1 fused
          eor.l  d4, d0         ; 1  
        
          move.l d0,d1          ; 2 fused
          and.l  #$00ff00ff,d1  ; 2 
        
          move.l d0,d2          ; 3 fused
          and.l  #$ff00ff00,d2  ; 3
        
          lsr.l  #8,d2          ; 4
        
          move.l (a1,d1.w*4),d3 ; 5 fused
          eor.l  d4, d3              ; 5
        
          swap   d1                  ; 6
        
          move.l (a2,d2.w*4),d4 ; 7 fused
          eor.l  d3, d4              ; 7
        
          swap   d2                  ; 8
        
          move.l (a3,d1.w*4),d3 ; 9 fused
          eor.l  d4, d3              ; 9
        
          subq.l #1,d7       ; 10
          bne.b .loop32
          
          move.l (a4,d2.w*4),d4        
          eor.l  d3, d4
    

Proposed:
|D|REG|W|SC|1|M|A|BD|1|S|Y|

This would allow things like:

add.l {d1,d4*16}, d2 ; d2=d2+{d1+d4*16}
move.l (a0,-d0*4), d0
lea 12(d2,-d3*16), a0

D=Data/Address register selection
REG=register
W=Word/Long selection
SC=Scale
B=Base suppress
I=Index suppress
BD=Base displacement
IS=Index/indirect selection

M=Memory suppress (1=no cache access, passes the calculated data)
  Could be used for other things for the LEA instruction.
A=Address/data selection (for base register)
X=indeX negate (alternatively invert)
S=extra scaling bit

Anyway, for novel people you are right.

3) Allow "<<" and a shift size as well as '*' for index scale     Example: move.l (1234+a0+d0<<7)     Reason: <<7 might be easier than *128 for some people/applications

I prefer multiplication, which is easier to read.

For me:
* 4 -> longword.
<< 2 -> ? Not so immediate to understand.

The older representations would of course be allowed too but something along these lines could be used for official documentation. The new style Motorola 68k syntax that primarily changed 1234(a0) to (1234,a0) is a nice improvement.

I agree.

If we make the calcuation in the EA more complex,
then the timing weill get worse and we will reduce our maximum clockrate.

Regarding using DN as base:
This is not good IMHO because of two reasons.
We would then need another new DN Read-Port: This drives Chip-costs higher.
We would also create a new hazard point.
Instructions working with the DN register in the two previous cycle would create a bubble. The correct recognise these hazards we will need to add extra tacking logic.
Also we can NOT update Dn Base registers as the EA does not have a write Port to the Dn Registers.
These are a lot drawbacks...

Regarding the extra Scale modes.
Adding an extra Bit for the scale mode looks tempting from the software point of few. But it will double our MUX area needed to do the SHIFT in the EA-Unit. This looks bad from a HW designers point of view because its costly and could reduce our clockrate.
I'll have to measure this to see how much room we have here before we looks performance...