[FFmpeg-devel] [PATCH 4/7] doc/developer.texi: document the use of other languages than C
Lynne
dev at lynne.ee
Thu Nov 17 16:33:50 EET 2022
Nov 17, 2022, 15:25 by jamrial at gmail.com:
> On 11/17/2022 11:17 AM, Lynne wrote:
>
>> Nov 17, 2022, 11:09 by anton at khirnov.net:
>>
>>> ---
>>> doc/developer.texi | 15 +++++++++++++--
>>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/doc/developer.texi b/doc/developer.texi
>>> index 01735e07f5..44da6e41af 100644
>>> --- a/doc/developer.texi
>>> +++ b/doc/developer.texi
>>> @@ -56,9 +56,9 @@ and should try to fix issues their commit causes.
>>> @anchor{Coding Rules}
>>> @chapter Coding Rules
>>> - at section C language features
>>> + at section Language
>>> -FFmpeg is programmed in the ISO C99 language, extended with:
>>> +FFmpeg is mainly programmed in the ISO C99 language, extended with:
>>> @itemize @bullet
>>> @item
>>> Atomic operations from C11 @file{stdatomic.h}. They are emulated on
>>> @@ -83,6 +83,17 @@ complex numbers;
>>> mixed statements and declarations.
>>> @end itemize
>>> +Other languages than C may be used in special cases:
>>> + at itemize @bullet
>>> + at item
>>> +NASM is preferred for x86 SIMD or other x86 assembly. Inline assembly and
>>> +intrinsics should be avoided, unless there is a strong reason to use them (e.g.
>>> +code that needs to be inlined).
>>>
>>
>> We don't accept x86 intrinsics, so should isn't really appropriate.
>> Also, a word for other architectures would do.
>> Something like this maybe:
>>
>> @item
>> NASM is required for x86 assembly. Inline assembly should be avoided,
>> unless there's a strong reason to use it (e.g. code that has to be inlined).
>> Intrinsics or other assembly flavours are not accepted for x86.
>>
>
> This is already not the case. See the stuff in libavutil/x86/intmath.h
> Intrinsics are ok as long as they are single instructions for inlined stuff, much like with inline asm.
> Builtins are obviously preferred, but they tend to be GCC/Clang only and at times limited in scope.
>
I think it's niche enough to avoid mentioning it and deal with it if we need to.
More information about the ffmpeg-devel
mailing list