[XviD-devel] Am I crazy?

Michael Militzer michael at xvid.org
Mon Apr 19 15:04:15 CEST 2004


Quoting Radek Czyz <syskin at ihug.com.au>:

> Let me stress that I am fully aware of the problems with gcc. I also
> like nasm, and I've written that.
> Michael Militzer wrote:
> > 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. 
> I think you completely missed my point - the main pros of gcc code is
> the ablity to produce debug info (we were just talking about code
> profiling, it's very difficult to do without debug info) and the ability
> to use C data structures. I never even mentioned instruction reordering
> because I'm not even convinced if it's a good thing.
> I also never wanted to include inline assembler/intrinsics in our C
> sources, because they should remain ANSI C. Inlining could only be done
> by ICL, it's doing that already, but only for .c files of course.
> I now understand that it will never happen - but please, if you are
> explaining why, make some reference to what I've written.

Hm, now did your initial mail mention the words 'inline assembler' and
'intrinsics' or not? ;-) One could also have the impression that you
stressed inline assembly more than debug info - but of course, I was also
referring to Jim's mail, so I was referring to the whole discussion.

BTW: If it's only about debug info, then I'm even more convinced that
switching to gcc might be no good idea. In order to really have an 
advantage for debugging and profiling, all asm code must be converted to
gcc (AT&T style syntax) which is no trivial task (when we want the
ported code to work without any new bugs). This is a lot of work only to
get the debugging info - imho it wouldn't justify the efforts. Because
just in order to profile the time that is spent on the different asm
functions, you don't really need the debugging info (unless you want to
use tools like CodeAnalyst)...


More information about the XviD-devel mailing list