[FFmpeg-devel] [PATCH 4/7] doc/developer.texi: document the use of other languages than C

[James Almer]

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.

> @item
> For other architectures, GAS syntax should be used for assembly.
> Inline assembly should be avoided, unless there's a good reason to use it.
> Intrinsics are acceptable, but not recommended.
> 
> Other architectures also have different assembly syntax versions,
> but it's so niche, it's not really worth mentioning.
> 
> Other patches look good.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".