cmp.l #30,d0
  sgt d1
  and.l #10,d1
  sub.l d1,d0

Not limited to have 16 bit d0. 4 cycles and not needed EXTB instruction since #10 is contained in the lower 8 bits => plain 68000 code.

Obviously, these instructions are coupled too, so no advantage in superscalar execution.

The above is not a problem.
I'll explain you why.

1) The 68050 has to write ports.
    One for the EA-Unit, and one for the ALU.
2) Also the 68050 uses result forwarding on both of them.

The Write-port of the EA-Unit is used by the following instructions:
1) Address modes that alter the Adress pointer
  (An)+  and -(An)
2) By ADDI, SUBI, ADDQ AN, ... and friends 

These instructions use the EA-Writeport to update the Addres-register.
The result of the EA-Unit is forwarded to the next Instruction using the EA-Unit and also to following instructions using the Addressregister.

This means stuff like this works without any problem
clr (An)+
clr (An)+
clr (An)+

The updated content of An is forwarded to the next instruction in time.

The 2nd write port belongs to the ALU.
The ALU does also forward is results.
This means a instruction group like this works without any penalty:

move D1,(A0)+
add D0,D1
neg D0

All the instructions are depending, nevertheless the 68050 can execute them all in 1 cycle each.

But there is one "gotcha".
This is happens when an ALU result is used by one of the following 2 instructions in the EA-Unit. The 68050 can not forward in time in this case of course. The reason that result forwarding is impossible is that the ALU stage is simple executed later than the EA-unit. This means when the first instruction reaches the ALU the 2nd already left the EA_unit.

Typical example is this one:
move (A0,D0),D1
neg D0

D0 is used in the EA-stage - but only updated in the ALU stage.
If the 68050 runs into such code is has to issues 2 wait cycles.
The bubble can be reduced and removed by adding other instructions inbetween.

This behavior is by design of the 68K architecture.
This problem is shared with all other 68K CPUs.
E.g. The 68060 will create just the same penalty in this example.

But this case is relative rare and the bubble can easily be avoided by instrution reordering.

Did this help?

Cheers

So normally this combination would need to wait until the CMP went down the complete pipeline before the jump can be executed.
 
 
So we look at the pipeline diagram, then we can see:
 
Unit diagram:
  1) Fetch/ICache
  2) Decoder
  3) Register load
  4) EA-Unit
  5) DCache-Load
  6) ALU Operation
  7) Register-Store/DCache-Store
 
That "normally" a jump after the CMP is expensive.
In our case the pipeline is even short "only" 6 clocks for this.
Other CPU would pay up to 30 clocks for a jump.
 
Luckily the 68050 does simply cheat on this one.
The decoder can rewrite the instructions to:
 
  cmp.l #30,d0
  subgt.l #10,d0

The SUB is now conditional.
The clue is that the SUB can be executed just normally.
The condition is not needed early like with the branch - its only needed in the very last stage, the writeback stage.
This means the rewritten instruction does not hurt the pipeline anymore. And the SUB can be executed just after the CMP.
 

Nice isnt't it?

Cheers
Gunnar

        # if i > 30 then i = i - 10
     
        slti  t0, i, 31   # t0 = i .lt. 31
        addi  t1, i, -10  # t1 = i-10
        movz  i, t1, t0   # if t0 .eq. 0 then i=t1
    

Very clever.  I imagine the best way is if we could just write the branch form and the compiler reworked it to the most efficient way for the CPU.  And if it could do this for all patterns then we wouldn't have to worry about it and just write the most easily read.

I imagine that human ingenuity means that someone somewhere will be able to create code patterns that weren't predicted and which the compiler/optimiser didn't know how to rework more efficiently than a clever assembler coder could.

Gunnar von Boehn wrote:

The instruction does indeed quite a lot of work. :-) The 68050 can do this amount of work in 1 clock because of its pipelined design. Unit diagram: 1) Fetch/ICache 2) Decoder 3) Register load 4) EA-Unit 5) DCache-Load 6) ALU Operation 7) Register-Store/DCache-Store

Thanks for that; now I understand and appreciate pipelining.  Cool existing solution.

Gunnar von Boehn wrote:

The predication conversion is supposed to rewrite BCC branches to become much faster!

Cool.  I didn't even know to think that such a solution was about so thanks for volunteering this.  It adds to my general understanding of things.  I imagine it increases the number of required instructions fairly significantly?  But so beneficial.

All of this CPU writing and testing you are doing at the moment is being done virtually at the moment isn't it Gunnar?  Do you actually get to have any FPGAs to burn too and test your ideas?  Does that come later when it is all 'debugged'?  Does an FPGA version always behave exactly like the virtual version?  If it doesn't what sort of things cause the variances?  These would be interesting things for me just to know.  I'm unlikely to ever delve into CPU coding in a broad way but it is still fun to know these little things.

subgt.l #10,d0

I have been wanting instructions like that since 1992!

gone gahgah wrote:

Do you actually get to have any FPGAs to burn too and test your ideas?

Yes, we have several FPGA dev-boards even including big Virtex and Stratix boards. But development in the simulator is faster so I prefer doing this.

This is by the way very normal.
Today all CPUs are developed in using simulator environments.

Cheers

  subgt.l #10,d0
  

Inside the 68050 :
- all instructions are 3 operant instructions
- and all instructions have a condition code.

The 68K family sometimes uses conditions codes and sometimes 3 opperants - so its easier for the hardware to have this internally always.

So far we do not expose this to the user with new opcodes.
Doing this would mean we would need to "invent" new instructions.

To be honest I'm not sure if we should ever do this.
What do you think?

> The 68K family sometimes uses conditions codes and sometimes 3
> opperants - so its easier for the hardware to have this internally > always.

Cool, that makes it really powerfull, just like e.g. ARM in ARM32 mode or other processors :)

> So far we do not expose this to the user with new opcodes.
> Doing this would mean we would need to "invent" new instructions.

> To be honest I'm not sure if we should ever do this.
> What do you think?

I fear, you are right. If you always recognize such code
(conditional branch over following instruction) and take
the  shortcuts, you do optimization while staying quite
compatible, so no need to have new opcodes for that and
it runns on other 68k processors.

On the other hand ... if you maybe decide to add things
like vector instructions, array min/max, norm etc. to
some maybe future (far far away) 68080 then I would also
make the conditional instructions available in the future
(then it does not matter anyway because you have a lot of
new instructions).

Btw.: I think I missed all discussion about Robin capabilities
and 3d Core capabilities. Could you give me a hint in which
forum post to find some information about instruction set,
vector processing, parallel instructions etc. in Robin and
the 3D core? Just interessted as I was programming such things
the last 10 years :-)

they are working on a compiler that compilers and then runs code to see how fast is goes then compiles it in a different way and test again, then compairs the run time, and takes the fastest code.

Then the same code can be recompiled using the collected
information for optimization, usually gives a few % more speed.

Marcel Verdaasdonk wrote:

I think we should do the same thing IBM is upto with there new compiler.     they are working on a compiler that compilers and then runs code to see how fast is goes then compiles it in a different way and test again, then compairs the run time, and takes the fastest code.

The 68k knows two main branch types.
Conditional Branches - which need the condition codes which are available at the end of the Pipeline.

And unconditional branches.
Unconditional branches are:
BRA,BSR,JSR,JMP and also RTS,RTE,...

The unconditional branches can ge grouped in four different types of how to address to jump to is calculated.
 
a) JUMP to an absolute address, included in the opcode
JMP $100000
 
b) PC-relative JUMP
BRA.w label
BSR label
JMP label(pc)
 
c) A jump to a calculated Effective Address (EA)
JMP -240(A6)
 
d) Jump to an address located in memory.
RTS

The branch acceleration unit can on its own handle the branch types A and B. (A) is easy to handle as the address is contained in the instructions.
(B) is also easy to handle as only an addition to the PC is needed.
The branch acceleration unit contains three adders-unit for this purpose.
 
The branch type C needs access to the register set and an EA calculation.
This can only be done by the EA-unit. Which comes 3 stages later in the pipe. This is way this type of branch take longer.
 

The branch to memory (RTS) is basicly a
MOVE.l (A7)+,PC
And therefore needs also be done later in the pipeline

Did this answer your question?

Would that make sense?

I disagree, it whould be used only in few cases like this.

Personally, if new instructions will be added, I strongly prefer math+cc instructions, eg:

    cmp.l #30,d0
    subgt.l #10,d0

cheers ;-)

There is one challenge with doing "CC" on any type of instruction - which I should not hide.

If someone sees a clever solution to this problem please speak up!

CC-ing an instruction can be easily done on any type of instruction with do their alteration only in the ALU-stage.
If an instruction does any type of alteration in the EA-stage then this is very difficult to "CC" is the condition codes are not available in that early stage.

In other words:
move (a0),D0  - can be easily CC'ed
as it only alter D0, and this is done in th ALU-stage.

move (a0)+,D0 -- is a problem as it alter the content of A0 in the EA-stage also.

Any idea?

Firsts, I don't know much on HW development :-P

Idea #1: place the CC test before in the pipeline:

Unit diagram:
    1) Fetch/ICache
    2) Decoder
    3) Register load
    3-bis) CC test, continue if true
    4) EA-Unit
    5) DCache-Load
    6) ALU Operation
    7) Register-Store/DCache-Store

Idea #2: allow CC-test only for specified EA (eg: allowed for (a0), not allowed for (a0)+ )

Idea #3: insert a rollback stage after ALU operation stage:

Unit diagram:
    1) Fetch/ICache
    2) Decoder
    3) Register load
    4) EA-Unit
    5) DCache-Load
    6) ALU Operation
    6-bis) CC rollback test
    7) Register-Store/DCache-Store