[FFmpeg-devel] [PATCH 1/7] configure: drop support for complex functions

[FFmpeg-devel] [PATCH 1/7] configure: drop support for complex functions

[Anton Khirnov]

They are not used since 520a5d33f0ea9f8838dbc7282470db700d248065.
---
 configure | 25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/configure b/configure
index e6470dc03b..868d11567b 100755
--- a/configure
+++ b/configure
@@ -1317,21 +1317,6 @@ int main(void){ $func(); }
 EOF
 }
 
-check_complexfunc(){
-    log check_complexfunc "$@"
-    func=$1
-    narg=$2
-    shift 2
-    test $narg = 2 && args="f, g" || args="f * I"
-    disable $func
-    test_ld "cc" "$@" <<EOF && enable $func
-#include <complex.h>
-#include <math.h>
-float foo(complex float f, complex float g) { return $func($args); }
-int main(void){ return (int) foo; }
-EOF
-}
-
 check_mathfunc(){
     log check_mathfunc "$@"
     func=$1
@@ -2224,11 +2209,6 @@ INTRINSICS_LIST="
     intrinsics_neon
 "
 
-COMPLEX_FUNCS="
-    cabs
-    cexp
-"
-
 MATH_FUNCS="
     atanf
     atan2f
@@ -2403,7 +2383,6 @@ HAVE_LIST="
     $(add_suffix _inline   $ARCH_EXT_LIST)
     $ARCH_FEATURES
     $BUILTIN_LIST
-    $COMPLEX_FUNCS
     $HAVE_LIST_CMDLINE
     $HAVE_LIST_PUB
     $HEADERS_LIST
@@ -6541,10 +6520,6 @@ for func in $MATH_FUNCS; do
     eval check_mathfunc $func \${${func}_args:-1} $libm_extralibs
 done
 
-for func in $COMPLEX_FUNCS; do
-    eval check_complexfunc $func \${${func}_args:-1}
-done
-
 # these are off by default, so fail if requested and not available
 enabled avisynth          && { require_headers "avisynth/avisynth_c.h avisynth/avs/version.h" &&
                                { test_cpp_condition avisynth/avs/version.h "AVS_MAJOR_VER >= 3 && AVS_MINOR_VER >= 7 && AVS_BUGFIX_VER >= 1 || AVS_MAJOR_VER >= 3 && AVS_MINOR_VER > 7 || AVS_MAJOR_VER > 3" ||
-- 
2.35.1

_______________________________________________
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".

[FFmpeg-devel] [PATCH 2/7] doc/developer.texi: move the language feature section higher up

[Anton Khirnov]

It makes more sense to first describe the language we are using and only
then document how to format code in it, rather than the reverse.
---
 doc/developer.texi | 104 ++++++++++++++++++++++-----------------------
 1 file changed, 52 insertions(+), 52 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index cf918ac6b1..8e6d9d8730 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -56,6 +56,58 @@ and should try to fix issues their commit causes.
 @anchor{Coding Rules}
 @chapter Coding Rules
 
+@section C language features
+
+FFmpeg is programmed in the ISO C90 language with a few additional
+features from ISO C99, namely:
+
+@itemize @bullet
+@item
+the @samp{inline} keyword;
+
+@item
+@samp{//} comments;
+
+@item
+designated struct initializers (@samp{struct s x = @{ .i = 17 @};});
+
+@item
+compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
+
+@item
+for loops with variable definition (@samp{for (int i = 0; i < 8; i++)});
+
+@item
+Variadic macros (@samp{#define ARRAY(nb, ...) (int[nb + 1])@{ nb, __VA_ARGS__ @}});
+
+@item
+Implementation defined behavior for signed integers is assumed to match the
+expected behavior for two's complement. Non representable values in integer
+casts are binary truncated. Shift right of signed values uses sign extension.
+@end itemize
+
+These features are supported by all compilers we care about, so we will not
+accept patches to remove their use unless they absolutely do not impair
+clarity and performance.
+
+All code must compile with recent versions of GCC and a number of other
+currently supported compilers. To ensure compatibility, please do not use
+additional C99 features or GCC extensions. Especially watch out for:
+
+@itemize @bullet
+@item
+mixing statements and declarations;
+
+@item
+@samp{long long} (use @samp{int64_t} instead);
+
+@item
+@samp{__attribute__} not protected by @samp{#ifdef __GNUC__} or similar;
+
+@item
+GCC statement expressions (@samp{(x = (@{ int y = 4; y; @})}).
+@end itemize
+
 @section Code formatting conventions
 
 There are the following guidelines regarding the indentation in files:
@@ -121,58 +173,6 @@ int myfunc(int my_parameter)
 ...
 @end example
 
-@section C language features
-
-FFmpeg is programmed in the ISO C90 language with a few additional
-features from ISO C99, namely:
-
-@itemize @bullet
-@item
-the @samp{inline} keyword;
-
-@item
-@samp{//} comments;
-
-@item
-designated struct initializers (@samp{struct s x = @{ .i = 17 @};});
-
-@item
-compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
-
-@item
-for loops with variable definition (@samp{for (int i = 0; i < 8; i++)});
-
-@item
-Variadic macros (@samp{#define ARRAY(nb, ...) (int[nb + 1])@{ nb, __VA_ARGS__ @}});
-
-@item
-Implementation defined behavior for signed integers is assumed to match the
-expected behavior for two's complement. Non representable values in integer
-casts are binary truncated. Shift right of signed values uses sign extension.
-@end itemize
-
-These features are supported by all compilers we care about, so we will not
-accept patches to remove their use unless they absolutely do not impair
-clarity and performance.
-
-All code must compile with recent versions of GCC and a number of other
-currently supported compilers. To ensure compatibility, please do not use
-additional C99 features or GCC extensions. Especially watch out for:
-
-@itemize @bullet
-@item
-mixing statements and declarations;
-
-@item
-@samp{long long} (use @samp{int64_t} instead);
-
-@item
-@samp{__attribute__} not protected by @samp{#ifdef __GNUC__} or similar;
-
-@item
-GCC statement expressions (@samp{(x = (@{ int y = 4; y; @})}).
-@end itemize
-
 @section Naming conventions
 All names should be composed with underscores (_), not CamelCase. For example,
 @samp{avfilter_get_video_buffer} is an acceptable function name and
-- 
2.35.1

_______________________________________________
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".

[FFmpeg-devel] [PATCH 3/7] doc/developer.texi: update the language feature section

[Anton Khirnov]

It is currently very out of touch with reality.

* declare we are using C99 fully, rather than C90 plus extensions
* mention our use of stdatomic.h
* mention forbidden C99 features, like VLAs and complex numbers
---
 doc/developer.texi | 49 ++++++++++++----------------------------------
 1 file changed, 12 insertions(+), 37 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 8e6d9d8730..01735e07f5 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -58,54 +58,29 @@ and should try to fix issues their commit causes.
 
 @section C language features
 
-FFmpeg is programmed in the ISO C90 language with a few additional
-features from ISO C99, namely:
-
+FFmpeg is programmed in the ISO C99 language, extended with:
 @itemize @bullet
 @item
-the @samp{inline} keyword;
-
-@item
-@samp{//} comments;
-
-@item
-designated struct initializers (@samp{struct s x = @{ .i = 17 @};});
-
-@item
-compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
-
-@item
-for loops with variable definition (@samp{for (int i = 0; i < 8; i++)});
-
-@item
-Variadic macros (@samp{#define ARRAY(nb, ...) (int[nb + 1])@{ nb, __VA_ARGS__ @}});
-
-@item
-Implementation defined behavior for signed integers is assumed to match the
-expected behavior for two's complement. Non representable values in integer
-casts are binary truncated. Shift right of signed values uses sign extension.
+Atomic operations from C11 @file{stdatomic.h}. They are emulated on
+architectures/compilers that do not support them, so all FFmpeg-internal code
+may use atomics without any extra checks. However, @file{stdatomic.h} must not
+be included in public headers, so they stay C99-compatible.
 @end itemize
 
-These features are supported by all compilers we care about, so we will not
-accept patches to remove their use unless they absolutely do not impair
-clarity and performance.
-
-All code must compile with recent versions of GCC and a number of other
-currently supported compilers. To ensure compatibility, please do not use
-additional C99 features or GCC extensions. Especially watch out for:
+Compiler-specific extensions may be used with good reason, but must not be
+depended on, i.e. the code must still compile and work with compilers lacking
+the extension.
 
+The following C99 features must not be used anywhere in the codebase:
 @itemize @bullet
 @item
-mixing statements and declarations;
-
-@item
-@samp{long long} (use @samp{int64_t} instead);
+variable-length arrays;
 
 @item
-@samp{__attribute__} not protected by @samp{#ifdef __GNUC__} or similar;
+complex numbers;
 
 @item
-GCC statement expressions (@samp{(x = (@{ int y = 4; y; @})}).
+mixed statements and declarations.
 @end itemize
 
 @section Code formatting conventions
-- 
2.35.1

_______________________________________________
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".

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

[Anton Khirnov]

---
 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).
+
+@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:
-- 
2.35.1

_______________________________________________
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".

[FFmpeg-devel] [PATCH 5/7] doc/developer.texi: move editor configuration under formatting

[Anton Khirnov]

It logically belongs there.
---
 doc/developer.texi | 67 +++++++++++++++++++++++-----------------------
 1 file changed, 34 insertions(+), 33 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 44da6e41af..d0e2e04a2d 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -119,6 +119,40 @@ The presentation is one inspired by 'indent -i4 -kr -nut'.
 The main priority in FFmpeg is simplicity and small code size in order to
 minimize the bug count.
 
+@subsection Vim configuration
+In order to configure Vim to follow FFmpeg formatting conventions, paste
+the following snippet into your @file{.vimrc}:
+@example
+" indentation rules for FFmpeg: 4 spaces, no tabs
+set expandtab
+set shiftwidth=4
+set softtabstop=4
+set cindent
+set cinoptions=(0
+" Allow tabs in Makefiles.
+autocmd FileType make,automake set noexpandtab shiftwidth=8 softtabstop=8
+" Trailing whitespace and tabs are forbidden, so highlight them.
+highlight ForbiddenWhitespace ctermbg=red guibg=red
+match ForbiddenWhitespace /\s\+$\|\t/
+" Do not highlight spaces at the end of line while typing on that line.
+autocmd InsertEnter * match ForbiddenWhitespace /\t\|\s\+\%#\@@<!$/
+@end example
+
+@subsection Emacs configuration
+For Emacs, add these roughly equivalent lines to your @file{.emacs.d/init.el}:
+@lisp
+(c-add-style "ffmpeg"
+             '("k&r"
+               (c-basic-offset . 4)
+               (indent-tabs-mode . nil)
+               (show-trailing-whitespace . t)
+               (c-offsets-alist
+                (statement-cont . (c-lineup-assignments +)))
+               )
+             )
+(setq c-default-style "ffmpeg")
+@end lisp
+
 @section Comments
 Use the JavaDoc/Doxygen  format (see examples below) so that code documentation
 can be generated automatically. All nontrivial functions should have a comment
@@ -215,39 +249,6 @@ Casts should be used only when necessary. Unneeded parentheses
 should also be avoided if they don't make the code easier to understand.
 @end itemize
 
-@section Editor configuration
-In order to configure Vim to follow FFmpeg formatting conventions, paste
-the following snippet into your @file{.vimrc}:
-@example
-" indentation rules for FFmpeg: 4 spaces, no tabs
-set expandtab
-set shiftwidth=4
-set softtabstop=4
-set cindent
-set cinoptions=(0
-" Allow tabs in Makefiles.
-autocmd FileType make,automake set noexpandtab shiftwidth=8 softtabstop=8
-" Trailing whitespace and tabs are forbidden, so highlight them.
-highlight ForbiddenWhitespace ctermbg=red guibg=red
-match ForbiddenWhitespace /\s\+$\|\t/
-" Do not highlight spaces at the end of line while typing on that line.
-autocmd InsertEnter * match ForbiddenWhitespace /\t\|\s\+\%#\@@<!$/
-@end example
-
-For Emacs, add these roughly equivalent lines to your @file{.emacs.d/init.el}:
-@lisp
-(c-add-style "ffmpeg"
-             '("k&r"
-               (c-basic-offset . 4)
-               (indent-tabs-mode . nil)
-               (show-trailing-whitespace . t)
-               (c-offsets-alist
-                (statement-cont . (c-lineup-assignments +)))
-               )
-             )
-(setq c-default-style "ffmpeg")
-@end lisp
-
 @anchor{Development Policy}
 @chapter Development Policy
 
-- 
2.35.1

_______________________________________________
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".

[FFmpeg-devel] [PATCH 6/7] doc/developer.texi: drop a misplaced sentence from code formatting section

[Anton Khirnov]

It describes a general development policy, not code formatting. It is
also not true, as these days we tend to prioritize correctness, safety,
and completeness over code size.
---
 doc/developer.texi | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index d0e2e04a2d..a2719e7518 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -116,9 +116,6 @@ K&R coding style is used.
 @end itemize
 The presentation is one inspired by 'indent -i4 -kr -nut'.
 
-The main priority in FFmpeg is simplicity and small code size in order to
-minimize the bug count.
-
 @subsection Vim configuration
 In order to configure Vim to follow FFmpeg formatting conventions, paste
 the following snippet into your @file{.vimrc}:
-- 
2.35.1

_______________________________________________
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".

[FFmpeg-devel] [PATCH 7/7] doc/developer.texi: extend and update naming conventions

[Anton Khirnov]

Bring it up to date with current practice, as the current text does not
cover everything. Drop the reference to unprefixed exported symbols,
which do not exist anymore.
---
 doc/developer.texi | 43 +++++++++++++++++++++++++++----------------
 1 file changed, 27 insertions(+), 16 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index a2719e7518..48c27f3005 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -191,39 +191,50 @@ int myfunc(int my_parameter)
 @end example
 
 @section Naming conventions
-All names should be composed with underscores (_), not CamelCase. For example,
-@samp{avfilter_get_video_buffer} is an acceptable function name and
-@samp{AVFilterGetVideo} is not. The exception from this are type names, like
-for example structs and enums; they should always be in CamelCase.
 
-There are the following conventions for naming variables and functions:
+Names of functions, variables, and struct members must be lowercase, using
+underscores (_) to separate words. For example, @samp{avfilter_get_video_buffer}
+is an acceptable function name and @samp{AVFilterGetVideo} is not.
 
-@itemize @bullet
-@item
-For local variables no prefix is required.
+Struct, union, enum, and typedeffed type names must use CamelCase. All structs
+and unions should be typedeffed to the same name as the struct/union tag, e.g.
+@code{typedef struct AVFoo @{ ... @} AVFoo;}. Enums are typically not
+typedeffed.
 
+Enumeration constants and macros must be UPPERCASE, except for macros
+masquerading as functions, which should use the function naming convention.
+
+All identifiers in the libraries should be namespaced as follows:
+@itemize @bullet
 @item
-For file-scope variables and functions declared as @code{static}, no prefix
-is required.
+No namespacing for identifiers with file and lower scope (e.g. local variables,
+static functions), and struct and union members,
 
 @item
-For variables and functions visible outside of file scope, but only used
-internally by a library, an @code{ff_} prefix should be used,
-e.g. @samp{ff_w64_demuxer}.
+The @code{ff_} prefix must be used for variables and functions visible outside
+of file scope, but only used internally within a single library, e.g.
+@samp{ff_w64_demuxer}. This prevents name collisions when FFmpeg is statically
+linked.
 
 @item
 For variables and functions visible outside of file scope, used internally
 across multiple libraries, use @code{avpriv_} as prefix, for example,
 @samp{avpriv_report_missing_feature}.
 
+@item
+All other internal identifiers, like private type or macro names, should be
+namespaced only to avoid possible internal conflicts. E.g. @code{H264_NAL_SPS}
+vs. @code{HEVC_NAL_SPS}.
+
 @item
 Each library has its own prefix for public symbols, in addition to the
 commonly used @code{av_} (@code{avformat_} for libavformat,
 @code{avcodec_} for libavcodec, @code{swr_} for libswresample, etc).
 Check the existing code and choose names accordingly.
-Note that some symbols without these prefixes are also exported for
-retro-compatibility reasons. These exceptions are declared in the
-@code{lib<name>/lib<name>.v} files.
+
+@item
+Other public identifiers (struct, union, enum, macro, type names) must use their
+library's public prefix (@code{AV}, @code{Sws}, or @code{Swr}).
 @end itemize
 
 Furthermore, name space reserved for the system should not be invaded.
-- 
2.35.1

_______________________________________________
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".

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

[Lynne]

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.
_______________________________________________
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".

Re: [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@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".
_______________________________________________
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".

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

[Lynne]

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.

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH 1/7] configure: drop support for complex functions

[Paul B Mahol]

On 11/17/22, Anton Khirnov <anton@khirnov.net> wrote:
> They are not used since 520a5d33f0ea9f8838dbc7282470db700d248065.
> ---
>  configure | 25 -------------------------
>  1 file changed, 25 deletions(-)
>
> diff --git a/configure b/configure
> index e6470dc03b..868d11567b 100755
> --- a/configure
> +++ b/configure
> @@ -1317,21 +1317,6 @@ int main(void){ $func(); }
>  EOF
>  }
>
> -check_complexfunc(){
> -    log check_complexfunc "$@"
> -    func=$1
> -    narg=$2
> -    shift 2
> -    test $narg = 2 && args="f, g" || args="f * I"
> -    disable $func
> -    test_ld "cc" "$@" <<EOF && enable $func
> -#include <complex.h>
> -#include <math.h>
> -float foo(complex float f, complex float g) { return $func($args); }
> -int main(void){ return (int) foo; }
> -EOF
> -}
> -
>  check_mathfunc(){
>      log check_mathfunc "$@"
>      func=$1
> @@ -2224,11 +2209,6 @@ INTRINSICS_LIST="
>      intrinsics_neon
>  "
>
> -COMPLEX_FUNCS="
> -    cabs
> -    cexp
> -"
> -
>  MATH_FUNCS="
>      atanf
>      atan2f
> @@ -2403,7 +2383,6 @@ HAVE_LIST="
>      $(add_suffix _inline   $ARCH_EXT_LIST)
>      $ARCH_FEATURES
>      $BUILTIN_LIST
> -    $COMPLEX_FUNCS
>      $HAVE_LIST_CMDLINE
>      $HAVE_LIST_PUB
>      $HEADERS_LIST
> @@ -6541,10 +6520,6 @@ for func in $MATH_FUNCS; do
>      eval check_mathfunc $func \${${func}_args:-1} $libm_extralibs
>  done
>
> -for func in $COMPLEX_FUNCS; do
> -    eval check_complexfunc $func \${${func}_args:-1}
> -done
> -
>  # these are off by default, so fail if requested and not available
>  enabled avisynth          && { require_headers "avisynth/avisynth_c.h
> avisynth/avs/version.h" &&
>                                 { test_cpp_condition avisynth/avs/version.h
> "AVS_MAJOR_VER >= 3 && AVS_MINOR_VER >= 7 && AVS_BUGFIX_VER >= 1 ||
> AVS_MAJOR_VER >= 3 && AVS_MINOR_VER > 7 || AVS_MAJOR_VER > 3" ||
> --
> 2.35.1
>

Fine

> _______________________________________________
> 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".
>
_______________________________________________
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".

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

[Anton Khirnov]

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.

-- 
Anton Khirnov
_______________________________________________
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".

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

[Lynne]

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.
_______________________________________________
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".