Just found this new instruction in Intel manual:

MOVBE - Move Data After Swapping Bytes

fasm 1.69.00 doesn't know it.

A pity there is no support for MOVBE r16/32/64, r16/32/64

Yeah, it's weird that they don't implemented it. However, it is still useful because BSWAP can work with register only.

Yes, looks like a nice instruction. How is it classified - is it SSE4 related?

It's classified among Miscellaneous Instructions (together with LEA, NOP, ...) in Basic Architecture manual. Indicated by CPUID.01H:ECX.MOVBE[bit 22].

Hmm, perhaps that's why I missed it. Its introduction is not that much different from the one of POPCNT instruction (which is also indicated by its own bit, CPUID.01H:ECX.POPCNT[bit 23]), but while POPCNT is listed as SSE4 instruction, MOVBE is not. Quite a mess.

(both register operands are not allowed)

Can someone test it? Maybe its undocumented, but works?

Seems like the first steppings of Core 2 don't support this instruction so it will be hard to find someone able to test it

Maybe I have you misunderstood but it is in the Instruction Set Reference A-M. (Vol. 2A 3-657), so it is documented.

Yes you did

He meant that perhaps "movbe reg, reg" is supported despite the operand combination is undocumented.

I've tried to test on my brother's computer but seems to be a too old Core2 because "movbe [var], edx" crashed the application.

With PSHUFB already added to SSE[?], MOVBE seems pointless, unless it is optimized (unlike the string instructions) to be faster than MOV/BSWAP.

Seems redundant.

r22, but PSHUFB needs either the FPU state or SSE state restored while MOVBE can work with GRPs.

I don't know the real intent for this instruction but perhaps it is to make networking drivers faster by storing in network order (big-endian) and reading with a direct conversion to native format (litte-endian) in a single step?

It seems like a very elegant instruction to generally operate on big-endian fields in data structures (including the network addresses, but also perhaps ASN.1/BER structures, smart card APDUs, etc.).

I thought I must have to be honest That would have been a too easy one.

LOAD+BSWAP will always be faster because there are many ways to throw it to the uop-schedulers. MOVBE is hindered with constant uops and therefore will penalize performance. Moreover this instruction seems not to replace BSWAP, but add [mem] capability to it.

If it is this silent and you have to test a separate bit for it (i.e. SSE4 doesn't guarantee this bit being set) then this is the perfect formula for failure.

Summary:
-macroop instuction (at least 2 uops)
-already has an elegant replacement as MOV reg,mem+BSWAP reg
-is not guaranteed on newer CPUs
-is not made popular with advertising



I don't get this instruction ... it seems to be some instruction from the times of LOOP and AAA and such...

But in the opposite direction you would have to do BSWAP reg + MOV mem,reg + BSWAP reg

...or MOV rtemp,reg + BSWAP rtemp + MOV mem,rtemp

(me thinks intel compiler fails to produce optimal code with BSWAP?)

Tomasz and bitRAKE - you might be on to something - I tend to agree.

I think MOVBE would be most useful in text sorting. Network address computations are hardly a case for optimising your code, but sorting data can take a considerable time in some cases and a simple optimisation with MOVBE will help a lot.