GCC mmx support

[toffer]

When looking to assembly code produces by gcc, i was shocked, that it wasn't translated to mmx or sse (compiler switches turned on!), something like:

a[0] += b[0]
a[1] += b[1]
a[2] += b[2]
a[3] += b[3]

The code around is vectorized too, in the same manner. Gcc won't assemble it mmx or something natively? (gcc 4.2)

[Matt Mahoney]

That's why I wrote paq7asm

[toffer]

Ok, one more thing: is gcc's inline assembler stable? Compiling with optimization seems to mess up the code... The gcc inline assembler normally worked for me, but this seems to be strange?!

I've done a piecewise test of my new mixing code, here's a small piece of disassembly:

Compiled with -O0:

/APP

/* Start */
movq mm0, [ecx]
movd mm2, edx
punpcklwd mm2, mm2
punpcklwd mm2, mm2
pmulhw mm0, mm2
pmulhw mm1, mm2
movq [ecx], mm2

/* End */

/NO_APP
mov ebx, 0
mov esi, ecx

which is ok and produces correct results, however with -O2 or 3:

/APP

/* Start */
movq mm0, [ecx]
movd mm2, edx
punpcklwd mm2, mm2
punpcklwd mm2, mm2
pmulhw mm0, mm2
pmulhw mm1, mm2
movq [ecx], mm2

/* End */

/NO_APP
mov DWORD PTR [esp+4], 32768

The bold line stores 1<<15 and OVERWRITES a mixing result. Why the hell does this happend?! Constrains and input/output are correct...

Matt, is this the reason, why you used nasm?

The version is 3.4.5

[Matt Mahoney]

I used nasm because I wanted the code to work with other compilers like Borland, Mars, VC++, etc., not just g++. nasm also works in Linux (as yasm), but masm and tasm don't.

I didn't mess with mixing C++ and assembler in the same function. g++ has some strange syntax to tell the compiler which registers you are using, but I didn't bother. If every function is either pure C++ or pure assembler there is no problem.

Also, isn't mm1 uninitialized?

[toffer]

Yes it is, but this is just a rough copy and paste, i missed its value. The original mixer update function is several times longer... As i said, i just tested each few lines of code seperatley; since i'm not familiar with mmx , but with 64 bit asm ^^. I usually use gcc's inline asm, but only with at&t syntax disabled - it my eyes it's redundant and horrible

I managed to get a mixer update of 8 inputs twice as fast as my c++ version with only 4 inputs. However this bug disappeared, i don't know why?!

But i figured out, that the main speed hit is a 32 bit / 32 bit division! Without this, the code would overall be about 4 times faster

EDIT: good news for me - i managed to replace the division by a multiplication and a table lookup This even improves compression! Maybe i can put everything together this weekend - there will be a massive imrpovement (i could improve sfc to 11.423.424 bytes without any higher order modelling)

[Matt Mahoney]

What's wrong with the MMX code in paq7/8?

Yes, division is slow. paq doesn't use it anywhere except for initialization.

[toffer]

I knew division is slow, but i didn't expect it eating up more than 70% of the mixer adjustment time.

There's nothing wrong with paq's MMX. I just wanted to use gcc's inline asm, since you don't have a function call overhead (stack frame, call, ret, etc...), when the function is inlined. This caused a 10% speed increase in my tests, so it is worth it.