| Message ID | 20221117100942.6217-4-anton@khirnov.net |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,1/7] configure: drop support for complex functions | expand |
| Context | Check | Description |
|---|---|---|
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
Nov 17, 2022, 11:09 by anton@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 > > -@section C language features > +@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: > +@itemize @bullet > +@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. @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.
On 11/17/2022 11:17 AM, Lynne wrote: > Nov 17, 2022, 11:09 by anton@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 >> >> -@section C language features >> +@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: >> +@itemize @bullet >> +@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Nov 17, 2022, 15:25 by jamrial@gmail.com: > On 11/17/2022 11:17 AM, Lynne wrote: > >> Nov 17, 2022, 11:09 by anton@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 >>> -@section C language features >>> +@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: >>> +@itemize @bullet >>> +@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.
Quoting Lynne (2022-11-17 15:17:44) > Nov 17, 2022, 11:09 by anton@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 > > > > -@section C language features > > +@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: > > +@itemize @bullet > > +@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. > @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. My intent with this set is to make the document match the actual reality, not ideal aspirations. And the actual reality is - for x86, we have both intrinsics and inline asm. In my view (apparently shared by several other people) intrinsics are the lesser evil when nasm cannot be used. - intrinsics are commonly used for some other arches, like ppc or mips Also, the reason I didn's say anything about other platforms (most importantly ARM, but also GPU stuff etc.) is that I never wrote any code for them and don't really know the exact state. Patches welcome.
Nov 19, 2022, 15:22 by anton@khirnov.net: > Quoting Lynne (2022-11-17 15:17:44) > >> Nov 17, 2022, 11:09 by anton@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 >> > >> > -@section C language features >> > +@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: >> > +@itemize @bullet >> > +@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. >> @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. >> > > My intent with this set is to make the document match the actual > reality, not ideal aspirations. And the actual reality is > - for x86, we have both intrinsics and inline asm. In my view > (apparently shared by several other people) intrinsics are the lesser > evil when nasm cannot be used. > We do not accept intrinsics for any SIMD DSP code which is what this whole section is about. Using them in intmath.h and other parts are insignificant and therefore not worth mentioning. This is the reality, and neglecting to mention it _is_ misdocumenting. > - intrinsics are commonly used for some other arches, like ppc or mips > > Also, the reason I didn's say anything about other platforms (most > importantly ARM, but also GPU stuff etc.) is that I never wrote any code > for them and don't really know the exact state. Patches welcome. > That's why I suggested adding that part above.
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 -@section C language features +@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: +@itemize @bullet +@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). + +@item +Objective-C where required for interacting with macOS-specific interfaces. +@end itemize + @section Code formatting conventions There are the following guidelines regarding the indentation in files: