Re: "Xiph needs someone to help with assembly for MSVC!"

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.