Luca Barbato <lu_z...@gentoo.org> writes:
> 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.
More to the point, we are not those other projects, and we know what
works and what doesn't for us.
>> 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.
I'd like to elaborate and expand this list a little:
- Any non-trivial inline asm usually requires using undocumented
constructs. These are often not supported by non-gcc compilers, and
they can change or go away with any new gcc release.
- Compilers often generate inefficient code surrounding an inline asm
statement. If used in a loop, this can make a real difference.
- Many operations are unsafe to do inside an inline asm statement. Just
recently we ran into a problem caused by doing a jump within the asm
block. Manipulating the stack pointer is fraught with peril. Doing a
function call is entirely out of the question.
- Operand constraints frequently do not permit optimal code. For example:
- Auto-increment addressing is not possible.
- Allocating even/odd register pairs is not possible.
- Accurately describing side-effects is not possible, leaving a global
"memory" clobber as the only resort.
- Inline asm is difficult to read and work with. The extra layer of
syntax on top of the assembly requires extra mental effort to process
and obscures the details of the code.
--
Måns Rullgård
m...@mansr.com
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
