theora dev - Oct 2008 - "Xiph needs someone to help with assembly for MSVC!"

Hello,

I write to you for the announcement in this blog:
http://blog.hartwork.org/?p=86.

I am interested in the open-source solution proposed in this article
(the preprocessor-macros solution).

Have you solved the problem?
Does the offer still stands?

Kind Regards,

Fernando Pelliccioni.
Buenos Aires, Argentina

I had forgotten about this.

On 10/2/08, Fernando Pelliccioni <fpelliccioni at gmail.com>
wrote:
> Does the offer still stands?
I believe so.  I reckon most projects that use assembly optimizations
like Theora do not have anything specific for MSVC.  Are you good at
this?

-Ivo

Fernando Pelliccioni wrote:
> Hello,
> 
> I write to you for the announcement in this blog:
> http://blog.hartwork.org/?p=86.
> 
> I am interested in the open-source solution proposed in this article
> (the preprocessor-macros solution).
I would suggest using a compiler which understands GCC-style assembly 
syntax such as Intel's ICC, rather than making the effort to rewrite. 
Since this is for MSVC users, the fact that it is non-free is moot.

Otherwise, it is relatively straightforward to write macros which expand 
to MSVC or GCC style syntax, such as

#ifdef GCC
#define asm_op_3(instruction, a, b, c) instruction %a,%b,%c
#else
#define asm_op_3(instruction, a, b, c) instruction c,b,a
#endif

The major difference being the order of operands is exactly reversed, 
which is easy to deal with using a macro. The only other thing to worry 
about is how to specify C variables from assembly. GCC uses complicated 
constraints whereas MSVC can refer to variables directly.

#ifdef GCC
#define asm_c_var(x) %x
#define bind_asm_c_var(name, constraint) (name) constraint (name)
#else
#define asm_c_var(x) x
#define bind_asm_c_var(name, constraint)
#endif

So you can then write
asm
{
	asm_op_2(movd, asm_c_var(foo), xmm1);
	asm_op_3(pushfd, 0xd, xmm1, xmm2);
	asm_inputs
	bind_asm_reg(foo, "m,r")
	asm_outputs
	asm_clobbers
};

Etcetera.

Chris

I think that the idea is to have a utility that makes the code
portable. Like the boost philosophy.

int val1, val2;

GNU Assembler:
    asm
    (
        "movl %%eax, %0;"
        "movl %%ebx, %1;"

         : "=r" ( val1 ), "=r" ( val2 )
    );

MASM:
   __asm
    {
         movl val1, eax
         movl val2, ebx
     };


En Preprocessor code:

    asm_open
            asm_op_2(movl , asm_c_var(val1), eax);
            asm_op_2(movl , asm_c_var(val2), ebx);
            asm_outputs
            bind_asm_reg(val1, "=r")
            bind_asm_reg(val2, "=r")
            asm_inputs
            asm_clobbers
    asm_close


I don't known how to count the 'asm_c_var' entries to convert to
'%0',
'%1', ... '%n' ...

Regards,
Fernando Pelliccioni.

On Thu, Oct 2, 2008 at 11:14 AM, Chris Brien <chris.brien at tandberg.com>
wrote:
> Fernando Pelliccioni wrote:
>>
>> Hello,
>>
>> I write to you for the announcement in this blog:
>> http://blog.hartwork.org/?p=86.
>>
>> I am interested in the open-source solution proposed in this article
>> (the preprocessor-macros solution).
>
> I would suggest using a compiler which understands GCC-style assembly
syntax
> such as Intel's ICC, rather than making the effort to rewrite. Since
this is
> for MSVC users, the fact that it is non-free is moot.
>
> Otherwise, it is relatively straightforward to write macros which expand to
> MSVC or GCC style syntax, such as
>
> #ifdef GCC
> #define asm_op_3(instruction, a, b, c) instruction %a,%b,%c
> #else
> #define asm_op_3(instruction, a, b, c) instruction c,b,a
> #endif
>
> The major difference being the order of operands is exactly reversed, which
> is easy to deal with using a macro. The only other thing to worry about is
> how to specify C variables from assembly. GCC uses complicated constraints
> whereas MSVC can refer to variables directly.
>
> #ifdef GCC
> #define asm_c_var(x) %x
> #define bind_asm_c_var(name, constraint) (name) constraint (name)
> #else
> #define asm_c_var(x) x
> #define bind_asm_c_var(name, constraint)
> #endif
>
> So you can then write
> asm
> {
>        asm_op_2(movd, asm_c_var(foo), xmm1);
>        asm_op_3(pushfd, 0xd, xmm1, xmm2);
>        asm_inputs
>        bind_asm_reg(foo, "m,r")
>        asm_outputs
>        asm_clobbers
> };
>
> Etcetera.
>
> Chris
>

Fernando Pelliccioni wrote:
> Have you solved the problem?
> Does the offer still stands?
>
>   
I think I did that job last years december for the decoder.

I first revamped / re-scheduled the existing GCC based functions and 
then did a half-automated translation to MSVC.

The trick was to use the objconv utility. That tool is able to translate 
the GCC compiled object file to Intel-style assembler.  It also was a 
great help because I was able to translate the flexible register style 
of GCC to the explicit register style of the MSVC inline assembler.

Anyway: I'm still a strong believer that it would be a damn good idea to 
get rid of the compiler dependent inline assembler stuff and move the 
asm-code into a *real* assembler-file. For x86 we have a well defined 
ABI that we works surprisingly well acrorss multiple operating systems. 
NASM as an assembler would be my first choice because it works on all 
relevant x86 platforms and is very easy to install (no big surprise as 
it's a single-file executable).

If we can motivate the theora mainainers to go this way I'd vulanteer 
and rewrite the code.

The days of inline assembler are over anyways. For MSVC you can't 
compile inline assembler in 64 bit mode anymore, and other architectures 
beside x86 have their own needs as well. For the C64x+ DSP you write 
something called linear assembler if you want maximal performance. That 
stuff is neither C nor assembler. It's something inbetween.

Besides that: I do have a working port for the C64x+ DSP I just 
mentioned. I also toy around with a port to the ARMv6-architecture 
(ARM11 and ARM Cortex-A8). Some experimental code for the NEON-SIMD unit 
exists as well.