The discussion with "Amiga Believer" about the pros and cons of the Motorola 96000 DSP made me think a bit.
The 96000 looks from the ASM dialect a lot like the 68K but has some difference. The 96000 support some instructions which the 68K does not have.

But all of those missing instructions would be easy to add the 68K.
So here is a list of Stuff that the 96000 has and we not.

In general we could add any of those instructions to the 68050.
But I would like that we do not add new features hastily and only add features of which we are really sure that they are of significant benefit.

Maybe we could brainstorm about the value of these instructions:

ABS    Absolute integer Value
SHIFT  Immidiate Shift allowing > 8 bits
FF1    Find First 1
BScc    Conditional BSR
Jcc    Conditional JMP
JScc    Conditional JSR
JOIN    Src.LW -> Dst.HW
JOINB  Src.LB -> Dst.HB
ORC    Or with Complement
SPLIT  Src.HW  -> Dst.LW (sign extented)
SPLITB  Src.HB  -> Dst.LB

The detailed description of the instruction is in the 96000 user manual (see freescale website)

So what are your thoughts?

I think that especially these three would be very useful. They would make life easier for the 68k programmer.

Thank you

Greetings,
Thomas

For example:
Lets say we want to add this instruction:
LSL.L #9,Dn

Lets say because of encoding space limitations we find no 16bit encoding for this but only a 32bit encoding.

If this would be the case we could also do the same work by using 2 instructions:
E.g
LSL.L #8,Dn
LSL.L #1,Dn

Of course the two instruction would take 2 clocks instead of 1.
But if we "enhance" the CPU Decoder it could merge those 2 instruction into 1. Thereby doing these 2 instructions in 1 cycle.

The net effect would be the same as adding a new 32bit encoding but without even needing to add a new encoding.
This means our CPU would run faster on old code and new code without that we need to change the existing 68k Compilers. :-)

Another merge example:

MOVE.L D0,D1
LSL.L #8,D1
LSL.L #1,D1

These 3 instructions could in theory be all merged into 1.

Another example:
It would be great if we coudl do BSRcc in 1 cycle.
Only the encoding is challenging.

But maybe we could encode it like this:
Bcc
BSR

Then it would be backward compatible with the old 68K CPUs
and if the Decoder is smart enough still be executed in 1 cycle.

What do you think?

This one is the equivalent of JScc but could be a predecated jump or some such similar thing:

    Bcc.b label
    JSR label2
label:

Jcc could be implemented with this:

    Bcc.b label
    JMP label2
label:

All we'd need is a way to reverse the condition code in the macro assembler.  Otherwise we'd have to make a macro for every condition code for each new instruction.

I would like to apply to become member of the Team.

Hope this is the right place to ask?

I think I could mainly contribute in the areas signal processing
implementations (work with DSPs since 99, lately with vector
processors), instruction set discussions (started with Amiga 87,
68k, ARM, ... experience) and some floating point issues (started to implement some 16bit floating point stuff in Verilog in a friends open source DSP project, http://code.google.com/p/ajardsp/).

/Br

Denis

People sharing our AMIGA ambition and our mind set are always welcome. It would be best to have a quick call to discuss all possibilities in detail. Can you email me your phone number to gunnar@greyhound-data.com ?

    abs MACRO
        tst.\0 \1
        bpl.b .skip\@
        neg.\0 \1
      .skip\@:
        ENDM
 
  Now you have your instruction. Use like...
   
      abs.l d0
   
  Problem solved. Now please go write us your optimized audio software in assembler!

Many thanks for the good ideas.

Matt Hey wrote:

for n GT 16 moveq #n,dy lsl dy,dx ORC (NOR) not dy or dy,dx

Unfortunately those are difficult to merge.

I'll explain why, maybe we can then together create a table of good "fusion pairs" and instructions which we better add new.

The 68K ALU is in general designed like this:
2 register read (each 32bit) - operation - 1 register update (32 bit).

This means the following:

MOVE.L D0,D1 is implemented as
SrcA= D0
Srcb= D1
Dst = (SrcA & $ffffffff)

But MOVE.B D0,D1 is internally implemented like this:
SrcA = D0
SrcB = D1
Dst  = (A & $ff) OR (B & $ffffff00)

Because of this we have some limitations when we fuse pairs.

Rule: each ALU can only update one register per clock.
The below would update 2 registers therefore we can NOT merge them.

not dy
or dy,dx

SPLITB
   
rol.l #8,dy
mvs.b dy,dx ; ColdFire instruction
ror.l #8,dy

How about this:
MOVE.L Dy,Dx
LSR.L  #8,Dx
EXTB.L Dx

This version could have the same flag settings as the SPLIT instruction.

I'm not sure if we should go for 6 byte encodings.
If we can encode a new instruction using two old instructions in 4byte total - then this is good IMHO. But using 6 Byte might be on the edge.

What do you think?

Matt Hey wrote:

I think some of the 96000 fpu instructions are interesting but I'll save that for a fpu thread later ;).

Please feel free to share your thoughts about them!

This is true. But our free encoding space is also very limited.

In the A-range the 68000 room for 2 new full instructions using the form EA,DN and having B/W/L support.

This means we can not add many instructions that encode in 16bit.
But we can add many instructions that encode in 32bit.

Simple instructions that only use 1 operant like ABS Dn need less encoding space. We can certainly add a few of those in 16bit still.

One drawback is the 3 operands; if we don't want that, we could
have special DSP registers to e.g. store minumum/maximum value and the minumum/maximum index; after looping with this instruction you could simply read the values from that memory mapped register; while this is not very 68k like it would be very powerful for signal processing and save a lot of opcode space.

We could have 3 modes (similar to ARM):
68k basic version, 68k basic plus DSP instructions (with memory mapped or special registers or registers could be readable/writable with an extra move), 68k basic plus DSP plus SIMD?
 
 

Gunnar von Boehn wrote:

BScc    Conditional BSR   Jcc    Conditional JMP   JScc    Conditional JSR   JOIN    Src.LW -> Dst.HW   JOINB  Src.LB -> Dst.HB   ORC    Or with Complement   SPLIT  Src.HW  -> Dst.LW (sign extented)   SPLITB  Src.HB  -> Dst.LB     The detailed description of the instruction is in the 96000 user manual (see freescale website)     So what are your thoughts?

 
  Hm, not so many thoughts on the rest of the instructions.
 
 

swap + move.w (and maybe swap + move.w)

should read...

swap + move.w (and maybe move.w + swap)

I couldn't edit after someone else posted. I also had to use GT and LE instead of the greater than and less than signs because they are interpreted as html codes by the forum.

Gunnar von Boehn wrote:

Matt Hey wrote:   for n GT 16   moveq #n,dy   lsl dy,dx     ORC (NOR)   not dy   or dy,dx     Unfortunately those are difficult to merge.

I see. I don't think it's such a big loss in the case of ORC and ANDC. The blitter or other gfx hardware can be used if there is a lot of these logical operations. The shifting greater than 8 is more of a problem. As much as I want to limit adding new instructions, I think this a prime candidate. A single word encoding would save code space in the case of 2 consecutive shifts too. I'm thinking the RTM + CALLM or A_ instruction space looks like it might have room. The asl and lsl could have the same encoding. Immediate 16 (swap) and 32 (useless) would not be needed. That would leave 9-15 and 17-31. I don't like how leaving rotate out would be unbalanced and how the encoding would be ad hoc. Maybe someone will have a different idea.

SPLITB         rol.l #8,dy   mvs.b dy,dx ; ColdFire instruction   ror.l #8,dy       How about this:   MOVE.L Dy,Dx   LSR.L  #8,Dx   EXTB.L Dx     This version could have the same flag settings as the SPLIT instruction.

There are 2 "upper" bytes so there could be a SPLITB.L and and SPLITB.W. My code was for the former and yours the latter. Either one could be encoded differently...

SPLITBS.W (signed)

  move.l dy,dx
  lsr.l  #8,dx
  extb.l dx

SPLITBZ.W (unsigned)

  move.l dy,dx
  lsr.l  #8,dx
  mvz.b dx,dx

SPLITBS.L (signed)

  move.l dy,dx
  rol.l #8,dx
  extb.l dx

SPLITBZ.L (unsigned)

  move.l dy,dx
  rol.l #8,dx
  mvz.b dx,dx

I don't think the byte versions of SPLIT and JOIN are common enough to fuse let alone create a new instruction. The CF instructions mvz.b and mvs.b already make dealing with the byte easier and using a few instructions is more flexible and less confusing.

Another possibility to look at is the bit field instructions.  BFEXTU and BFEXTS would already be smaller than 3 instructions.
How fast will the bit field instructions be on the N68050 to a register?

I'm not sure if we should go for 6 byte encodings.   If we can encode a new instruction using two old instructions in 4byte total - then this is good IMHO. But using 6 Byte might be on the edge.

 
I never suggested a 6 byte encoded instruction. 4 bytes is quite enough for an instruction. I was stating that a macro would take at most 6 bytes and opposed creating an ABS instruction. Anything besides a 2 byte ABS instruction would not make sense.

Gunnar von Boehn wrote:

In the A-range the 68000 room for 2 new full instructions using the form EA,DN and having B/W/L support.

You really want to break 68k Mac emulators, don't you ? ;-)

Gunnar von Boehn wrote:

Simple instructions that only use 1 operant like ABS Dn need less encoding space. We can certainly add a few of those in 16bit still.

Area used by things such as ff1, bitrev, byterev have a few places left. So abs could fit in here. I'd also recommend adding a new BitCnt (bit counter), PopCnt if you prefer to name it like that.

The new A-line instructions could be enabled or disabled with a special Bit in the SR register. This way each task would could decide to be in AMIGA or MAC mode. The AMIGA OS could default to enabled, and the MAC-Emulator would disable them. Should be simple and fully compatible.
 
 

Phil G. wrote:

Gunnar von Boehn wrote:     Simple instructions that only use 1 operant like ABS Dn need less encoding space. We can certainly add a few of those in 16bit still.     Area used by things such as ff1, bitrev, byterev have a few places left. So abs could fit in here. I'd also recommend adding a new BitCnt (bit counter), PopCnt if you prefer to name it like that.

 
Yes, this makes perfect sense to me.
Popcount sounds very good.
So which encoding would you propose for POPCOUNT and ABS?

Regarding the Shift.
I wonder if adding an "extend" opcode would make sense.
Lets say we identify a 16bit opcode which is so far unused and has some free bits.
 
This opcode could be used to context sensitive extend the existing instructions:
Adding this opcode to the existing SHIFT #1,(ea) instruction would make it to an SHIFT #n,(ea)
 
And other instructions could be extended like this also ... Just a thought.