Using AMD notation, see Volume 4 from the AMD website
document downloads,

movupd xmm1, xmm2/mem128
movupd xmm1/mem128, xmm2

versus

movups xmm1, xmm2/mem128
movups xmm1/mem128, xmm2


movupd moves an unaligned vector of 2 x 64 bit floating points,

movups moves an unaligned vector of 4 x 32 bit floating points

HOWEVER neither instruction checks the actual bits,

ie AFAICT they are IDENTICAL in action and could be moving

say 2 qword's

whats the point of wasting opcodes on identical effect instructions?

why not just have:

mov_arbitrary_128_bit_pattern xmm1, xmm2/mem128
mov_arbitrary_128_bit_pattern xmm1/mem128, xmm2

?

and free up opcodes?

SSE does this all the time having different instructions which
only differ at the interpretative level, IDENTICAL at the h/w level.

checking the bit pattern in hardware would slow things down
and be pointless if you have type checking in software.

both have identical exceptions and there is no wrong bit format
exception.

if you want to copy memory fast you COULD use movapd

and the memory being copied could be bytes.

that would copy 16 bytes at a time,

movapd has identical effect to movaps, these being
the aligned versions of movupd and movups.

I have wondered this too.



How do you know they are the same at the hardware level?

See here for a discussion about this.

There much more:
movaps (SSE) vs. movapd (SSE2) vs. movdqa (SSE2).
the same for unaligned.
Uncached movntps, movntpd, movntdq.
xorps (SSE) vs. xorpd (SSE2) vs. pxor (since MMX)
same for other bit instructions.

Off-topic moved to http://board.flatassembler.net/topic.php?t=9137

If this document is any clue to Intel's design model, it seems that movupd+movups is simpler to implement, saving die space and losing only a bit of power. Having a conversion later would add one operation and that is bad, thinks Intel.

EDIT: the link: http://isdlibrary.intel-dispatch.com/isd/1999/Siggraph_Larrabee_paper.pdf