[XviD-devel] Am I crazy?
michael at xvid.org
Mon Apr 19 12:30:23 CEST 2004
Quoting suxen_drol <suxen_drol at hotmail.com>:
> On Mon, 19 Apr 2004 16:35:36 +0930 Radek Czyz <syskin at ihug.com.au> wrote:
> > Yeah, this is why I was thinking that we could - for starters - just
> > move assembler files from nasm to gcc's inline assembler, and leave it
> > there. There shouldn't be any impact (especially negative) if we do just
> > that.
> iam 'for' this, however it means new win32 developers must download gcc
> inorder to build xvid (fully). which gcc dist.? mingw, cygwin?
I am strongly against this proposal. First, did you really propose to
convert all nasm code into gcc style inline assembler? This is not: 'just
move assembler files from nasm to gcc's inline assembler' - rather it's
a major problem.
Apart from that, I don't really see the big advantage of using gcc for
asm code: So far, we did not only try to make XviD as portable as possible
but we also tried to make it 'compiler-friendly'. So basically you can
compile the c-code with whatever c compiler you like and if you want the
asm code, you just need to install nasm which is just _one_ small
executable file and available for all x86 platforms.
Now if you replace the nasm part by gcc, you'd need to install gcc to
compile XviD. gcc is a large package (much larger than nasm) and
potentially painful to install and setup (especially for non-linux users).
Also then XviD would be dependent on gcc - sure you still could compile
the non-asm files with another c-compiler, but there is not much reason
for this if you have gcc installed anyway. _In fact_ this would turn
XviD into a 'gcc only' project.
I also don't find the main pros of gcc, that have been mentioned, really
striking: intrinsics and inline assembly (and because of this potentially
faster code). Well, once you'll have asm code inlined with intrinsics
all over your c code, it's getting really painful to work with it. I
believe the maintainance of asm code in nasm style (seperate files, short
instructions, powerful macros) is much more simple.
Apart from that, I also don't believe that 'faster asm code thanks to
compiler optimizations' is an advantage at all: It might be possible that
some asm code gets faster after conversion from nasm to inline assembler because
the compiler will reorder the code or better pair instructions.
However this is no prove that inline asm would be faster or better. Rather
it's a prove that the nasm code could have been written better. If you're
a good asm coder, you don't want the compiler to reorder your code behind
your back, rather you want full control and want the code to be executed
exactly like you wrote it (this is a major reason for writing asm code).
Note that I'm not claiming I would be a good asm coder - certainly I'm
not. Nonetheless the above considerations might be important for really
good asm coders (like Skal)...
More information about the XviD-devel