I totally agree for point 2, of course.

For point 1, I think that it can be easy to find all available compilers and make some tests, but, again, it'll need some time to do all the checks.

For example: LSB==0 - assume forward branches as untaken, backward as taken, LSB==1 - do the reverse. and do everything else you've said.

This is great idea.

My idea 4) Instuction to "prepare condition" for conditional jump BEFORE jump.

like
.blah:
instruction1
instruction2
prepeq
instruction3
instruction4
bprep blah

where - prepeq - prepare condition for delayed jump - yes if equal.

bprep - jump if prepared condition is tet.

This way you CAN optimize code even in case of completely impredictable branches, as long as you can have more instructions
to execute after you know the condition.
prep instruction can be "0 cycle" IMHO.

This way you got what powerpc and ARM have - just different way.
on ARM you for example set what instructions update flags. if you
make one instruction that update flags, 10 that not and then conditional jump, you can have processor that will not have to refill pipeline on this conditional jump.
Higher end of ARM CPUs make use of that feature.
On powerPC it's similar IMHO, but i don't have enough knowledge.

on N68k you will sacrifice 2 extra bytes of code for this when it make sense, but it WILL give great adventage when jumps cannot be predicted.

NO BRANCH prediction algorithm can predict jumps that depends on input data - but this will allow decoder to know earlier that jump will/will not be taken

@Wojtek
Instructions like cmp.b #$12,d0 is encoded as $xxxx 0012. The upper byte of the extension word is padding that can be encoded to sign extend the data to a long value altering the instruction to be cmp.l #$12,d0. This saves a word per immediate long instruction and also a register as a moveq #$12,d1 + cmp.l d1,d0 is not needed. I hope that explains it as I don't have much time at work right now.

I said a sign extended 15bit value. Any 15bit value.

Way to many options.
This will slow the chip down - therefore not a good idea.

It may be possible - 1 bit to sign it's sign extended 15 bit value.
But no shifting/rotating.

There are reliable ways then a predication bits.

Our real goal is to implement a branch target cache.
A branch target cache does remember not only TAKEN/NOT TAKEN but it caches where branch did go to. This allows effective caching of even computed gotos. This makes AMIGA OS calls like this
  JSR -132(a6) take only 1 clock cycle. :-D
 

Yes, because of two reasons.

1) Your multicycle instructions are bad for going superscalar.
They will hurt our performance when we go super scalar.

2) An real chip (full custom desing) has different ways of creating logic. In an FPGA you ONLY have the logic cells and you need to create what you want with them. The result is that certain logic chains create huge multiplexers which will hurt the speed of the whole design. This is not what you want.

@Wojtek
The shifting and register use you suggest for the immediate value would not be so useful on the 68k. PPC does have instructions that load a word into the upper 1/2 of a register or load and shift instructions but it's necessary because the instructions must always be 32 bits and there is not room for a 32 bit immediate value. The CISC 68k can load a 32 bit immediate value so this is not necessary. It's really not that inefficient for the N68k to do an op.l #immediate,EA with it's large fetch either. It's nice to save a word though as most of the time the upper word is unused. Using moveq #immediate,d0 + op.l d0,EA works just as fast because of instruction fusion but uses a trash register and is limited to byte size immediate. For loading a value into the upper 1/2 of a register it may be possible to instruction fuse an op.size + swap. The now fast bitfield instructions provide some shift plus operation functionality as well. I prefer Gunnars encoding for 15 bit immediate long operations.

My branch idea does include the use of the least significant bit of bcc instruction's branch address as the hint just as you say. A LSB of 1 (odd address) would reverse the branch logic of the branch from the normal forward predicted not taken and backward predicted taken. This was originally suggested by ThoR but Gunnar really wants to use the bit to double the branch range. Your idea of prepcc + bprep is interesting. It looks like a delayed branch strategy which would probably work but it's a far departure from the 68k way. I think we want something that will work reasonably well with existing code, not introduce very many new instructions, and have flexibility. My idea does not solve the branch that depends on dynamic/computed data but it looks like Gunnar has a simple solution of storing the last branch destination in the branch cache making it faster if it is used again.

Perfect!

Gunnar von Boehn wrote:

Matt Hey wrote:       With base register update we have fast and small...               move.l ($20,a0)+,d0         move.l (a0)+,(a1)+         move.l (a0),d1       Tricky one.   How would you encode the first instruction?   Its more than (update An flag) as you combine two address modes in addition to this.

I would use bit 3 of the full extension word format (bd,An,Xn.SIZE*SCALE) if possible. Setting bit 3 would cause the calculated EA of ($20,a0) to be put in (update) the base register a0. In the example above, the index register would be suppressed.

Gunnar von Boehn wrote:

The current predication is only the start.   To be honest I'm not such a big fan of hint bits.   Old code will not benefit from them at all.

True, although it would be fairly easy to modify existing assembler (or disassembled) code to the correct branch logic. A profiler utility could also do the job. This would especially be good for 68020/68030 code (most Amiga programs) where the branch logic is reversed. Changing the hint bit is much easier than turning the branch around and doesn't require pulling the conditional code out of series or putting it in series to remain optimal. Putting the code in series for predication is always a good idea IMHO, but if it's faster to branch ahead and skip the predication and we know that's the common case, then programmers will not put the code in series. If we count on the branch cache history, we will have to take the slow route through the predication many times until the history says the branch is taken enough to skip the predication and just branch. Programmers will then not put the code in series as that is faster and there will be no possibility for predication of forward branches predicted as taken. Older code will not fully be optimal, but a consistent future API and future proof API will have been defined.

Gunnar von Boehn wrote:

And compilers do not them as they could turn the code around to match the static predication to work perfectly.

There is a problem that compilers don't do good branch optimization without profiler data. It would be possible to define the first option of an if then or case as the most likely used. Then the compiler could optimize the branches accordingly. Assembler inlines would be easier to write optimally. There are 3 possibilities here for enhancing compiled code with a hint bit. If the branch reverse bit doesn't get set correctly, then we are usually not that bad off.

Gunnar von Boehn wrote:

And statistics show that programmer do not use them effectively.

Many programmers don't use profilers or look at their compiled code either. The hint bit would allow fine tuning of branch optimizations for those that want it and encourage programmers to always put there code in series because that would always be the fastest way.

Gunnar von Boehn wrote:

There are reliable ways then a predication bits.

I don't know if you are talking about the hint bit or the predication counter bits in the branch cache I suggested.

Gunnar von Boehn wrote:

Our real goal is to implement a branch target cache.   A branch target cache does remember not only TAKEN/NOT TAKEN but it caches where branch did go to. This allows effective caching of even computed gotos. This makes AMIGA OS calls like this   JSR -132(a6) take only 1 clock cycle. :-D

Good. The 68060 branch cache has a target address as well as history and it is very effective. The predicted branch target would work well for library calls that are consistently going to the same place but not the greatest for jump tables. There is nothing to lose though as taking a chance is better than stalling.