On 8/21/12 10:27 AM, Babic, Nedeljko wrote:
We are working on other projects and there were no problems in using inline
assembly.
I'm not assuming we know ultimate truths, Libav is compiled using a
large number of C99 compilers for quite a number or specific targets,
for us inline assembly had been an hindrance in a number of situations.
I can accept that you have different stand based on your experience regarding
using inline
assembly and I would like to understand it so we could better comply with your
standard
and see if we have shortcomings in our approach.
So could you please elaborate a little on why you think that it is harder to
maintain inline
assembly code and what portability problems do you expect?
Let me make a short list initially:
- Compilers not supporting inline assembly
- Those will be slown down severely, using separate asm would make
them produce something not so crippled.
- Compilers not supporting all the inline assembly
- clang is getting quite good but from time to time trips on that on
different arches
- gcc register allocator had a long history of issues and other
compilers tend to have problems with certain constraints.
- Refactor concerns and templating
- one of the problems we experienced that hit us severely had been
with swscale, some optimization had been grafted in a
quite wrong way and templatized in an even more annoying way,
making it quite hard to change w/out a full rewrite.
To summarize, in-line assembly is good as long it is really necessary
and there aren't any options (e.g. inline function replacements for
2liners) but it is advised to use straight asm for larger bodies since
it makes easier to templatize if needed and it is sort of simpler to
move them around in case that part is refactored.
lu
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
