[meynaf]

Originally Posted by matthey

If a conditional or SELcc style instruction could replace all branches then we wouldn't have branches. SELcc is at its best when it can replace an IF/THEN/ELSE eliminating 2 branches. It would also be another possible tool for those evil branches which can't be predicted well.

Can you provide sample code ? This is what i was asking for.

Originally Posted by matthey

Yes, some CPU designs may choose not to use the branch hint bit and for others it may be the only branch prediction help as it is so cheap. Although many programmers will choose not to use a hint bit or optimize to this level, others may. I see PPC hint bits in much of Frank Wille's PPC assembler code for vbcc and most modern PPC processors don't use it. Amiga programmers may be more likely to use a hint bit because we like optimized code and we generally use slower processors and often in assembler.

But instead of the hint bit we could simply use backward taken / forward not taken and optimize by moving code around.

Originally Posted by matthey

Yes, this is a source of inconsistency for me. I prefer to look at the result size. How can you tell new programmers to use longword sizes when the result does not match the instruction size?

SWW.L would not be bad but REVW.L is more understandable, IMO. My preferred syntax is very clear at least. There may be too much use of REV with BREV.L, REVB.L and REVW.L though. Maybe REVB.L could be EREV.L or ESWAP.L for endian reverse or endian swap. I don't know. The originals aren't horrible either even if BYTEREV is a little long.

I like EREV. Some xREV for bits would be consistent then, but B is "single bit". Maybe LREV for longword reverse ?

Originally Posted by matthey

More addressing space is really the only good reason to move to 64 bit and there are other ways of working around this issue. I guess Gunnar would answer so I have 64 bit registers for my SIMD instructions. What happens if the SIMD gets floating point or grows to 128 bit registers though?

That's one of the reasons why i don't like the SIMD extensions. They get obsolete as soon as the next version comes out.

Originally Posted by matthey

The AND.L is simpler and what a compiler is most likely going to use. The AND.L #d16.w,Dn addressing mode is the same size as BFEXTU but it may be faster on some CPU implementations.

Peephole asm optimization can perhaps do the conversion.

Current compilers are able to use the MOVEQ+AND trick, so there is little use for AND.L #i16.
And anyway if we really want this, it takes a very small encoding space.

Originally Posted by matthey

I guess it depends on how you look at it. The addressing mode doesn't use much valuable encoding space but I guess you could say it uses a little encoding space in every instruction with an EA.

Count the number of code words, the difference is big.
Is it worth creating an addressing mode that only a handful instructions will use ? If we list all instructions where the immediate mode is available, we won't get a lot of them.

Originally Posted by matthey

I played with your mix and it is trickier than it first looks. It might have been a good algorithm for the programming competition. I came up with
the following.

mix:
; d0 = mask (trashed)
; d1 = number 1 (mixed result 1)
; d2 = number 2 (mixed result 2)
; d3 = scratch
   move.l d0,d3
   and.l d1,d3
   and.l d2,d0
   eor.l d3,d2
   eor.l d0,d1
   eor.l d3,d1
   eor.l d0,d2

Is this the correct operation? Is there shorter/faster/better code for it? What types of algorithms is this used for?

Yes this is the correct operation. There is a shorter way (same register layout as yours) :

 move.l d1,d3
 eor.l d2,d1
 and.l d0,d1
 eor.l d1,d2
 eor.l d3,d1

This kind of code is quite standard issue, i believe it would have been a poor competition entry.
What type of algorithms, well, aside of the classic c2p/p2c it's for whenever you need to exchange selected bits, i.e. extract a bit field or separate bits, while keeping the old value somewhere.
Many cases would go away if we had a BFEXG, though.

Originally Posted by matthey

I'm not a fan of the MIX EA,Rn:Rn using Rn:Rn which should be reserved for a high:low 64 bit value. I would just go for MIX EA,Rn,Rn. The ColdFire tried to limit instructions to 2 OPs also which is why it ended up with REM(S/U) EA,Dr : Dq when there is no 64 bit operation. It is confusing and didn't work for 64 bit REMS/REMU which is one of the reasons I created DIVUR/DIVSR. It also keeps me from using an alias of REMS->DIVSR and REMU->DIVSU like you suggested.

Either Da : Db or Da, Db, doesn't matter for me. Feel free to choose what you see fit, i won't pop up to contradict you there