[theora-dev] "Xiph needs someone to help with assembly for MSVC!"

[Timothy B. Terriberry]

Nils Pipenbrinck wrote:
> 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 

The problem is, of course, that this still requires maintaining multiple
versions of the code. x86-32 vs x86-64 at a minimum. The current GCC
inline assembler covers both architectures, as well as handling
different options like -fPIC, which changes the way global symbols are
accessed, etc. These things are totally irrelevant to the real goal,
which is accessing MMX registers and instructions, and I view the fact
that GCC takes care of them for me as a real benefit.

GCC inline assembly is simply more flexible than communicating only
across function calls via an ABI (and there are several ABI's, even for
x86). I realize that the same might not be said for MSVC inline
assembly. But you're asking us to give up real features for a) an
additional dependency and b) no reduction in maintership effort.

I also agree Microsoft's inability to ship decent compiler tools for
64-bit Windows is an issue, but that is a systemic problem with all
64-bit Windows development, which is why so few people actually bother.
I don't consider converting to nasm to gain 64-bit Windows support to be
a sufficiently compelling argument. Please feel free to try to persuade
me otherwise.

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

The problem is not getting someone to rewrite the code (although getting
someone to review those rewrites may be an issue). The problem is
getting someone to maintain it five years from now when nasm decides to
subtly change their syntax in a way that breaks compilation (again).

So the question becomes, is it easier to find one or more nasm
volunteers who understand all of the vagaries of all of the x86 ABIs on
all platforms, or is it easier to find one volunteer who understands gcc
and one who understands MSVC? If you think one guy working with nasm
from Windows is going to be able to maintain the code without testing
and debugging in Linux, I think you're quite mistaken. And the same goes
for the other direction. I suspect the pool of volunteers for the second
approach is also much larger. It's much easier to find someone who knows
the default tools on his or her primary platform.

> 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.

DSPs are always going to be a separate issue because of their insistence
on using their own, closed toolchains. Vendor lock-in is part of the
business model. Supporting them will always take work.

> 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.

So where are the patches?