[FFmpeg-devel] [DISCUSSION] Adding ARM64EC support to FFmpeg

[FFmpeg-devel] [DISCUSSION] Adding ARM64EC support to FFmpeg

[harish.rajaselvan--- via ffmpeg-devel]

Hi everyone,
 
I'm reaching out regarding ARM64EC support for FFmpeg on Windows.

I have been working on enabling ARM64EC compilation and have successfully built FFmpeg binaries for this target. To achieve this it required modifications to the build configuration files and to the gas-preprocessor.pl script (maintained in https://github.com/FFmpeg/gas-preprocessor). Should changes to gas-preprocessor.pl be submitted as a pull request to its repository, or also sent to this mailing list for review?
 
I would like to submit these patches upstream for review and feedback from the community in the near future in this thread. Please let us know if we can proceed with submitting them, or if there are any challenges we should anticipate for enabling for this target.
 
Additionally, I would like to know the point of contact for hosting ARM64EC binaries (for example, via btbn or gyan.dev), so that people targeting this platform can have access to FFmpeg builds for this target.
 
Looking forward to your feedback.
 
Thanks,
Harish Raja Selvan
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

On Mon, 22 Sep 2025, harish.rajaselvan--- via ffmpeg-devel wrote:

> I have been working on enabling ARM64EC compilation and have 
> successfully built FFmpeg binaries for this target. To achieve this it 
> required modifications to the build configuration files and to the 
> gas-preprocessor.pl script (maintained in 
> https://github.com/FFmpeg/gas-preprocessor). Should changes to 
> gas-preprocessor.pl be submitted as a pull request to its repository, or 
> also sent to this mailing list for review?

I'm not sure if we have a policy for this; reviewing it on the mailing 
list probably gives it more visibility than as a PR in a repo that very 
few follows.

> I would like to submit these patches upstream for review and feedback 
> from the community in the near future in this thread. Please let us know 
> if we can proceed with submitting them, or if there are any challenges 
> we should anticipate for enabling for this target.

Feel free to send patches for review - although I cannot guarantee that we 
are willing to integrate the changes.

As far as I can see, for building for ARM64EC with MSVC, the changes 
required mainly are for passing "-machine:arm64ec" to lib.exe, and for 
filtering out the -arm64EC option from the compiler command in 
gas-preprocessor.pl.

Such changes probably are straightforward and probably can be accepted.

If building with https://github.com/mstorsjo/llvm-mingw/releases (with the 
latest 2 releases), no such changes are needed, and it's possible to 
configure a build with just "--cross-prefix=arm64ec-w64-mingw32- 
--target-os=mingw32 --arch=aarch64".

The other, much more major issue, is that all aarch64 assembly may need to 
be tweaked to work in ARM64EC mode. This may need rewrites (or ugly 
conditionals) to avoid using registers that are forbidden in ARM64EC mode.

(Building with Clang makes this aspect much more straightforward, as Clang 
gives warnings about the use of forbidden registers, like "warning: 
register Q25 is disallowed on ARM64EC.".)

We would have to see the proposed patches to see if these changes are 
palatable or if they are too outrageous for us to want to take them 
upstream.

> Additionally, I would like to know the point of contact for hosting 
> ARM64EC binaries (for example, via btbn or gyan.dev), so that people 
> targeting this platform can have access to FFmpeg builds for this 
> target.

Upstream ffmpeg can't make any promises about this; you'd have to convince 
the developers providing those builds to do it. Personally, I'm 
unconvinced.

For users of the plain ffmpeg.exe binaries, I don't see any reason why 
anyone would want to run an ARM64EC version rather than a plain regular 
ARM64 build. (The main theoretical reason is if intending to load a binary 
x86_64 plugin, but I don't know what plugins that would be?)

The main reason for wanting an ARM64EC build of ffmpeg is for integrating 
into an app that still runs in emulated x86_64 mode - then you'd want 
linking against the libraries and not just using the commandline 
executable. I'm not familiar with those binary distributions, whether they 
include such libraries as well, or only the end executables. If they do 
provide libraries as well, I could see some value in it, but it's of 
course totally up to them whether they feel it's worth the effort (I doubt 
it).

// Martin

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Harish Raja Selvan via ffmpeg-devel]

[-- Attachment #1: Type: text/plain, Size: 5259 bytes --]

Hello,

Following up on the discussion above on ARM64EC support, I’ve prepared a patch to
update gas-preprocessor.pl that enables FFmpeg to be compiled for ARM64EC
target on Windows. This change ensures that -m flags are not eliminated for
ARM64EC target, allowing assembly files to preprocess as expected. This
avoids build failures.

The patch has been tested locally & allows FFmpeg to build successfully for
ARM64EC target. Attaching the patch file and in-lined here for your reference.

Thanks,
Harish Raja Selvan.

In-Lined patch:

diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index 62c1a04..b2e38c0 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -166,6 +166,7 @@ if ($as_type ne "armasm") {
     @gcc_cmd = grep ! /^-D/, @gcc_cmd;
 } else {
     @preprocess_c_cmd = grep ! /^-m/, @preprocess_c_cmd;
+    @preprocess_c_cmd = grep ! /^ARM64EC/, @preprocess_c_cmd;

     @preprocess_c_cmd = grep ! /^-G/, @preprocess_c_cmd;
     @preprocess_c_cmd = grep ! /^-W/, @preprocess_c_cmd;
@@ -195,7 +196,8 @@ if ($as_type ne "armasm") {
     # which doesn't support any of the common compiler/preprocessor options.
     @gcc_cmd = grep ! /^-D/, @gcc_cmd;
     @gcc_cmd = grep ! /^-U/, @gcc_cmd;
-    @gcc_cmd = grep ! /^-m/, @gcc_cmd;
+    @gcc_cmd = grep !/^-m/, @gcc_cmd if !grep /-arm64EC/, @gcc_cmd;
+    @gcc_cmd = grep ! /^-arm64EC/, @gcc_cmd;
     @gcc_cmd = grep ! /^-M/, @gcc_cmd;
     @gcc_cmd = grep ! /^-c$/, @gcc_cmd;
     @gcc_cmd = grep ! /^-I/, @gcc_cmd;
--
2.50.1.windows.1

________________________________
From: Martin Storsjö <martin@martin.st>
Sent: 22 September 2025 17:18
To: harish.rajaselvan--- via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
Cc: Harish Raja Selvan <harish.rajaselvan@multicorewareinc.com>
Subject: Re: [FFmpeg-devel] [DISCUSSION] Adding ARM64EC support to FFmpeg

On Mon, 22 Sep 2025, harish.rajaselvan--- via ffmpeg-devel wrote:

> I have been working on enabling ARM64EC compilation and have
> successfully built FFmpeg binaries for this target. To achieve this it
> required modifications to the build configuration files and to the
> gas-preprocessor.pl script (maintained in
> https://github.com/FFmpeg/gas-preprocessor). Should changes to
> gas-preprocessor.pl be submitted as a pull request to its repository, or
> also sent to this mailing list for review?

I'm not sure if we have a policy for this; reviewing it on the mailing
list probably gives it more visibility than as a PR in a repo that very
few follows.

> I would like to submit these patches upstream for review and feedback
> from the community in the near future in this thread. Please let us know
> if we can proceed with submitting them, or if there are any challenges
> we should anticipate for enabling for this target.

Feel free to send patches for review - although I cannot guarantee that we
are willing to integrate the changes.

As far as I can see, for building for ARM64EC with MSVC, the changes
required mainly are for passing "-machine:arm64ec" to lib.exe, and for
filtering out the -arm64EC option from the compiler command in
gas-preprocessor.pl.

Such changes probably are straightforward and probably can be accepted.

If building with https://github.com/mstorsjo/llvm-mingw/releases (with the
latest 2 releases), no such changes are needed, and it's possible to
configure a build with just "--cross-prefix=arm64ec-w64-mingw32-
--target-os=mingw32 --arch=aarch64".

The other, much more major issue, is that all aarch64 assembly may need to
be tweaked to work in ARM64EC mode. This may need rewrites (or ugly
conditionals) to avoid using registers that are forbidden in ARM64EC mode.

(Building with Clang makes this aspect much more straightforward, as Clang
gives warnings about the use of forbidden registers, like "warning:
register Q25 is disallowed on ARM64EC.".)

We would have to see the proposed patches to see if these changes are
palatable or if they are too outrageous for us to want to take them
upstream.

> Additionally, I would like to know the point of contact for hosting
> ARM64EC binaries (for example, via btbn or gyan.dev), so that people
> targeting this platform can have access to FFmpeg builds for this
> target.

Upstream ffmpeg can't make any promises about this; you'd have to convince
the developers providing those builds to do it. Personally, I'm
unconvinced.

For users of the plain ffmpeg.exe binaries, I don't see any reason why
anyone would want to run an ARM64EC version rather than a plain regular
ARM64 build. (The main theoretical reason is if intending to load a binary
x86_64 plugin, but I don't know what plugins that would be?)

The main reason for wanting an ARM64EC build of ffmpeg is for integrating
into an app that still runs in emulated x86_64 mode - then you'd want
linking against the libraries and not just using the commandline
executable. I'm not familiar with those binary distributions, whether they
include such libraries as well, or only the end executables. If they do
provide libraries as well, I could see some value in it, but it's of
course totally up to them whether they feel it's worth the effort (I doubt
it).

// Martin


[-- Attachment #2: 0001-ffmpeg-gas-preprocessor-enable-ARM64EC-compilation.patch --]
[-- Type: application/octet-stream, Size: 1666 bytes --]

[-- Attachment #3: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

On Tue, 23 Sep 2025, Harish Raja Selvan wrote:

> Following up on the discussion above on ARM64EC support, I’ve prepared a
> patch to
> update gas-preprocessor.pl that enables FFmpeg to be compiled for ARM64EC
> target on Windows. This change ensures that -m flags are not eliminated for
> ARM64EC target, allowing assembly files to preprocess as expected. This
> avoids build failures.

It is entirely unclear to me what -m flags you would expect to be seeing 
here. I can understand the part of the patch to filter out the flag 
-arm64EC, but I don't see where a flag "ARM64EC" would come from for 
preprocess_c_cd, or where any -m flags would come from.

To make sense of the patch, I would suggest you at least explain what kind 
of configure flags you are using in combination with these patches.

My attempts with ARM64EC with MSVC are configured with --arch=arm64 
--target-os=win32 --toolchain=msvc --extra-cflags="-arm64EC" 
--extra-ldflags="-machine:arm64ec". I guess you are doing something other 
than that, if you're getting -m flags somewhere.

Ideally, post both your build system patches and the gas-preprocessor 
patch at the same time.

Also, don't top post.

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Harish Raja Selvan via ffmpeg-devel]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

Hello,

Thank you for your feedback and questions about the ARM64EC patch.
I’m sharing the build system patch for enabling ARM64EC support in FFmpeg.
This patch addresses .def file generation for ARM64EC builds on Windows.

In-Lined patch:

diff --git a/compat/windows/makedef b/compat/windows/makedef
index add8222d13..59e300ab61 100755
--- a/compat/windows/makedef
+++ b/compat/windows/makedef
@@ -108,7 +108,12 @@ if [ -n "$NM" ]; then
               cut -d' ' -f3 |
               sed -e "s/^${prefix}//")
 else
-    dump=$(dumpbin.exe -linkermember:1 ${libname} |
+    member=1
+    arch=$VSCMD_ARG_TGT_ARCH
+    if [ "${arch^^}" = "ARM64EC" ]; then
+        member=32
+    fi
+        dump=$(dumpbin.exe -linkermember:${member} ${libname} |
               sed -e '/public symbols/,$!d' -e '/^ \{1,\}Summary/,$d' -e "s/ \{1,\}${prefix}/ /" -e 's/ \{1,\}/ /g' |
               tail -n +2 |
               cut -d' ' -f3)
@@ -121,7 +126,7 @@ list=""
 for exp in ${regex}; do
     list="${list}"'
 '$(echo "${dump}" |
-          grep "^${exp}" |
+          grep "^${exp}" | awk '!/\$exit_thunk/{print}' |
           sed -e 's/^/    /')
 done

--
2.50.0.windows.1

For reference, here is the configuration used to build FFmpeg with MSVC for ARM64EC:
I've also attached the same configuration in ffmpeg-arm64ec-msvc.config for convenience.

# find_ar_lib resolves to /usr/share/automake-1.16/ar-lib
AR_LIB="$(find_ar_lib)"
AR_CMD="${AR_LIB} lib.exe -machine:arm64ec"
ARCH="arm64"

"${SRC_DIR}/configure" \
    --toolchain=msvc \
    --target-os=win64 \
    --cc=cl.exe \
    --cxx=cl.exe \
    --extra-cxxflags="-arm64EC" \
    --extra-cflags="-arm64EC" \
    --extra-ldflags="/machine:arm64ec" \
    --as="armasm64.exe -machine ARM64EC" \
    --ld=link.exe \
    --ar="${AR_CMD}" \
    --arch="${ARCH}"

In my setup, this configuration requires the gas-preprocessor.pl patch, as the build otherwise ends with a “GNU assembler not found” error.

Thanks,
Harish Raja Selvan.

[-- Attachment #2: 0001-compat-windows-makedef-fix-.def-generation-for-ARM64.patch --]
[-- Type: application/octet-stream, Size: 2032 bytes --]

[-- Attachment #3: 0001-ffmpeg-gas-preprocessor-enable-ARM64EC-compilation.patch --]
[-- Type: application/octet-stream, Size: 1666 bytes --]

[-- Attachment #4: config-arm64ec-msvc.config --]
[-- Type: application/xml, Size: 480 bytes --]

[-- Attachment #5: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

On Tue, 30 Sep 2025, Harish Raja Selvan wrote:

> Thank you for your feedback and questions about the ARM64EC patch.
> I’m sharing the build system patch for enabling ARM64EC support in FFmpeg.
> This patch addresses .def file generation for ARM64EC builds on Windows.
> 
> In-Lined patch:
> 
> diff --git a/compat/windows/makedef b/compat/windows/makedef
> index add8222d13..59e300ab61 100755
> --- a/compat/windows/makedef
> +++ b/compat/windows/makedef
> @@ -108,7 +108,12 @@ if [ -n "$NM" ]; then
>                cut -d' ' -f3 |
>                sed -e "s/^${prefix}//")
>  else
> -    dump=$(dumpbin.exe -linkermember:1 ${libname} |
> +    member=1
> +    arch=$VSCMD_ARG_TGT_ARCH
> +    if [ "${arch^^}" = "ARM64EC" ]; then
> +        member=32
> +    fi

We shouldn't inspect any VSCMD_* env variables here in order to deduce the 
target architecture. (Also, how do you initialize the environment in order 
to get such a variable set? If you just open a regular arm64 VS command 
prompt, which AFAIK is the default environment for arm64ec compilation, I 
wouldn't expect such a variable to be set?)

Instead we need to deduce the architecture from something else here - 
potentially by passing some parameter from configure.

> +        dump=$(dumpbin.exe -linkermember:${member} ${libname} |
>                sed -e '/public symbols/,$!d' -e '/^ \{1,\}Summary/,$d' -e
> "s/ \{1,\}${prefix}/ /" -e 's/ \{1,\}/ /g' |
>                tail -n +2 |
>                cut -d' ' -f3)
> @@ -121,7 +126,7 @@ list=""
>  for exp in ${regex}; do
>      list="${list}"'
>  '$(echo "${dump}" |
> -          grep "^${exp}" |
> +          grep "^${exp}" | awk '!/\$exit_thunk/{print}' |

I presume the added awk expression here is just to filter out any line 
that doesn't match '$exit_thunk'? Why not just a "grep -v '$exit_thunk'"? 
And that can be in the dump expression as well, in order not to need to do 
that filtering for each expression. (If we add it to the dump expression, 
we do need to include it in both variants of the dump expression though; 
it's possible to build arm64ec with mingw style tools as well.)

For me, this doesn't really end up matching any symbols - I only get the 
data symbols. What does EXTERN_PREFIX end up being set to in your 
configurations; for me it's an empty string. Does it get set to "#" in 
your case?


> For reference, here is the configuration used to build FFmpeg with MSVC for
> ARM64EC:
> I've also attached the same configuration in ffmpeg-arm64ec-msvc.config for
> convenience.
> 
> # find_ar_lib resolves to /usr/share/automake-1.16/ar-lib
> AR_LIB="$(find_ar_lib)"
> AR_CMD="${AR_LIB} lib.exe -machine:arm64ec"

Why do you need any extra ar-lib here? This works fine for me with just 
AR_CMD="lib.exe -machine:arm64ec".

> ARCH="arm64"
> 
> "${SRC_DIR}/configure" \
>     --toolchain=msvc \
>     --target-os=win64 \
>     --cc=cl.exe \
>     --cxx=cl.exe \
>     --extra-cxxflags="-arm64EC" \
>     --extra-cflags="-arm64EC" \
>     --extra-ldflags="/machine:arm64ec" \
>     --as="armasm64.exe -machine ARM64EC" \
>     --ld=link.exe \
>     --ar="${AR_CMD}" \
>     --arch="${ARCH}"
> 
> In my setup, this configuration requires the gas-preprocessor.pl patch, as
> the build otherwise ends with a “GNU assembler not found” error.

Thanks - with this context, it's easier to review your gas-preprocessor 
patch.

As far as I can see, this builds fine without any extra modifications of 
ffmpeg, as long as gas-preprocessor is patched. Building with 
--enable-shared would require the suggested changes to makedef, but those 
changes aren't entirely right in order to work for me in my tests.

I have an alternative suggestion on how to do the gas-preprocessor patch - 
I'll send those patches and CC you on them.

Another alternative for gas-preprocessor would be to just look for the 
-arm64EC option, and inject the "-machine arm64ec" options implicitly in 
that case (it turns out I actually had such a patch lying around since 
experiments in 2021), but it's perhaps more transparent to force the 
caller of gas-preprocessor to provide the option.

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Harish Raja Selvan via ffmpeg-devel]

[-- Attachment #1: Type: text/plain, Size: 3933 bytes --]

Hello,

This patch adds support for ARM64EC builds on Windows by updating .def file generation logic for shared libraries and ensuring the correct machine flag is passed to lib.exe and dumpbin.exe.

In-Lined patch:

diff --git a/compat/windows/makedef b/compat/windows/makedef
index add8222d13..261e7d463f 100755
--- a/compat/windows/makedef
+++ b/compat/windows/makedef
@@ -48,7 +48,13 @@ trap 'rm -f -- $libname' EXIT
 if [ -n "$AR" ]; then
     $AR rcs ${libname} $@ >/dev/null
 else
-    lib.exe -out:${libname} $@ >/dev/null
+    machine_flag=""
+    case "$LDFLAGS" in
+    *"/machine:arm64ec"*)
+        machine_flag="-machine:arm64ec"
+        ;;
+    esac
+    lib.exe ${machine_flag} -out:${libname} $@ >/dev/null
 fi
 if [ $? != 0 ]; then
     echo "Could not create temporary library." >&2
@@ -108,10 +114,19 @@ if [ -n "$NM" ]; then
               cut -d' ' -f3 |
               sed -e "s/^${prefix}//")
 else
-    dump=$(dumpbin.exe -linkermember:1 ${libname} |
-              sed -e '/public symbols/,$!d' -e '/^ \{1,\}Summary/,$d' -e "s/ \{1,\}${prefix}/ /" -e 's/ \{1,\}/ /g' |
+    member=1
+    case "$LDFLAGS" in
+    *"/machine:arm64ec"*)
+        member=32
+        ;;
+    esac
+    dump=$(dumpbin.exe -linkermember:${member} ${libname} |
+              sed -e '/public symbols/,$!d' -e '/^ \{1,\}Summary/,$d' -e 's/^[[:space:]]*[0-9A-Fa-f]* //' -e "s/^${prefix}//" -e 's/^#//' |
               tail -n +2 |
-              cut -d' ' -f3)
+              cut -d' ' -f3 |
+              grep -v '\$exit_thunk$' |
+              grep -v '\$entry_thunk' |
+              grep -v '\$exit_thunk')
 fi

 rm ${libname}
diff --git a/configure b/configure
index 7828381b5d..fbf5ab38a4 100755
--- a/configure
+++ b/configure
@@ -6040,7 +6040,7 @@ case $target_os in
         SLIB_INSTALL_LINKS=
         SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
         SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a) $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
-        SLIB_CREATE_DEF_CMD='EXTERN_PREFIX="$(EXTERN_PREFIX)" AR="$(AR_CMD)" NM="$(NM_CMD)" $(SRC_PATH)/compat/windows/makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)'
+        SLIB_CREATE_DEF_CMD='LDFLAGS="$(LDFLAGS)" EXTERN_PREFIX="$(EXTERN_PREFIX)" AR="$(AR_CMD)" NM="$(NM_CMD)" $(SRC_PATH)/compat/windows/makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)'
         SHFLAGS='-shared -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a) -Wl,--disable-auto-image-base $$(@:$(SLIBSUF)=.def)'
         enabled x86_64 && objformat="win64" || objformat="win32"
         dlltool="${cross_prefix}dlltool"
@@ -6078,7 +6078,7 @@ case $target_os in
         SLIBSUF=".dll"
         SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
         SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
-        SLIB_CREATE_DEF_CMD='EXTERN_PREFIX="$(EXTERN_PREFIX)" $(SRC_PATH)/compat/windows/makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)'
+        SLIB_CREATE_DEF_CMD='LDFLAGS="$(LDFLAGS)" EXTERN_PREFIX="$(EXTERN_PREFIX)" $(SRC_PATH)/compat/windows/makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)'
         SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
         SLIB_INSTALL_LINKS=
         SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
--
2.50.1.windows.1

For reference, here is the configuration used to build FFmpeg with MSVC for ARM64EC:

AR_CMD="lib.exe -machine:arm64ec"
ARCH="arm64"

"${SRC_DIR}/configure" \
    --toolchain=msvc \
    --target-os=win64 \
    --cc=cl.exe \
    --cxx=cl.exe \
    --extra-cxxflags="-arm64EC" \
    --extra-cflags="-arm64EC" \
    --extra-ldflags="/machine:arm64ec" \
    --as="armasm64.exe -machine ARM64EC" \
    --ld=link.exe \
    --ar="${AR_CMD}" \
    --arch="${ARCH}" \
    --enable-shared

Thanks,
Harish Raja Selvan.

[-- Attachment #2: 0001-PATCH-v2-Fix-.def-file-generation-for-ARM64EC-builds.patch --]
[-- Type: application/octet-stream, Size: 4197 bytes --]

[-- Attachment #3: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

[-- Attachment #1: Type: text/plain, Size: 4161 bytes --]

Hi,

On Wed, 22 Oct 2025, Harish Raja Selvan wrote:

> This patch adds support for ARM64EC builds on Windows by updating .def file
> generation logic for shared libraries and ensuring the correct machine flag
> is passed to lib.exe and dumpbin.exe.

Thanks! This version is nicer than the previous ones, and almost looks 
good to me - but there are a couple of smaller details I'd still like to 
fix up.

See the attached patch for my final fixed up version of this; is that one 
ok for you? If it is, I would prefer going with that. I'm commenting 
inline below about the issues I found:

> diff --git a/compat/windows/makedef b/compat/windows/makedef
> index add8222d13..261e7d463f 100755
> --- a/compat/windows/makedef
> +++ b/compat/windows/makedef
> @@ -48,7 +48,13 @@ trap 'rm -f -- $libname' EXIT
>  if [ -n "$AR" ]; then
>      $AR rcs ${libname} $@ >/dev/null
>  else
> -    lib.exe -out:${libname} $@ >/dev/null
> +    machine_flag=""
> +    case "$LDFLAGS" in
> +    *"/machine:arm64ec"*)

Checking for a literal / here is overly restrictive, as the option can be 
passed as either /machine or -machine. We probably don't need to 
explicitly match either of the flags literally, it may be enough to look 
for "machine:arm64ec".

(Note that I think link.exe may accept these flags in uppercase too, and 
then we wouldn't match it. But it's probably ok to not catch that here...)

> +        machine_flag="-machine:arm64ec"
> +        ;;
> +    esac
> +    lib.exe ${machine_flag} -out:${libname} $@ >/dev/null
>  fi
>  if [ $? != 0 ]; then
>      echo "Could not create temporary library." >&2
> @@ -108,10 +114,19 @@ if [ -n "$NM" ]; then
>                cut -d' ' -f3 |
>                sed -e "s/^${prefix}//")
>  else
> -    dump=$(dumpbin.exe -linkermember:1 ${libname} |
> -              sed -e '/public symbols/,$!d' -e '/^ \{1,\}Summary/,$d' -e
> "s/ \{1,\}${prefix}/ /" -e 's/ \{1,\}/ /g' |
> +    member=1
> +    case "$LDFLAGS" in
> +    *"/machine:arm64ec"*)
> +        member=32
> +        ;;
> +    esac
> +    dump=$(dumpbin.exe -linkermember:${member} ${libname} |
> +              sed -e '/public symbols/,$!d' -e '/^ \{1,\}Summary/,$d' -e
> 's/^[[:space:]]*[0-9A-Fa-f]* //' -e "s/^${prefix}//" -e 's/^#//' |
>                tail -n +2 |
> -              cut -d' ' -f3)
> +              cut -d' ' -f3 |
> +              grep -v '\$exit_thunk$' |
> +              grep -v '\$entry_thunk' |
> +              grep -v '\$exit_thunk')

There's two checks for $exit_thunk here - the later one matches a wider 
pattern than the former one. So the former one can be skipped entirely.

The added sed expression 's/^[[:space:]]*[0-9A-Fa-f]* //' makes the later 
"cut" command redundant, so I suggest removing that for clarity. (In the 
updated patch I refactored this to require 1 or more occurrances of the 
hex digits, and match 1 or more spaces after that as well, to make sure it 
eats up all spaces.

For mingw mode, we use a separate invocation of $NM above. I've extended 
that with an expression to remove the leading '#' as well, and remove the 
entry/exit thunks. With that in place, this works fine for arm64ec mingw 
as well.

>  fi
>  
>  rm ${libname}
> diff --git a/configure b/configure
> index 7828381b5d..fbf5ab38a4 100755
> --- a/configure
> +++ b/configure
> @@ -6040,7 +6040,7 @@ case $target_os in
>          SLIB_INSTALL_LINKS=
>          SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
>          SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
> $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
> -        SLIB_CREATE_DEF_CMD='EXTERN_PREFIX="$(EXTERN_PREFIX)"
> AR="$(AR_CMD)" NM="$(NM_CMD)" $(SRC_PATH)/compat/windows/makedef
> $(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)'
> +        SLIB_CREATE_DEF_CMD='LDFLAGS="$(LDFLAGS)"
> EXTERN_PREFIX="$(EXTERN_PREFIX)" AR="$(AR_CMD)" NM="$(NM_CMD)"

This is the mingw version (where we pass NM=...) - here we don't need to 
check LDFLAGS, so we don't need to edit this line at all.

With those changes, in the attached patch, this looks good to me. I also 
extended the commit message a bit to mention the other subtle details in 
this change.

// Martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff; name=0001-Fix-.def-file-generation-for-ARM64EC-builds-on-Windo.patch, Size: 3947 bytes --]

From e1a23db7d5a87cbc737386c4bf64c2957721473d Mon Sep 17 00:00:00 2001
From: Harishmcw <harish.rajaselvan@multicorewareinc.com>
Date: Fri, 17 Oct 2025 18:03:44 +0530
Subject: [PATCH] Fix .def file generation for ARM64EC builds on Windows
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When building DLLs on ARM64EC, the default use of `dumpbin
-linkermember:1` fails because ARM64EC static libraries use a
different linker member format. Use `-linkermember:32` for ARM64EC
to correctly extract symbols.

Additionally, MSVC inserts $exit_thunk and $entry_thunk symbols
for ARM64EC to handle x64 ↔ ARM64 transitions. These are internal
thunks and must not be exported. Filter them out when generating
the .def file to avoid unresolved symbols or invalid exports.

Trim out the leading '#' on ARM64EC function symbols. This is only
relevant on ARM64EC, but it is benign to do that filtering on
all architectures (such symbols aren't expected on other
architectures).

Simplify the sed command by removing the symbol address with a
sed expression instead of a later "cut" command.

This ensures correct symbol extraction and stable DLL generation
on ARM64EC targets, while keeping behavior unchanged for other
Windows architectures.

Signed-off-by: Harishmcw <harish.rajaselvan@multicorewareinc.com>
---
 compat/windows/makedef | 25 ++++++++++++++++++++-----
 configure              |  2 +-
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/compat/windows/makedef b/compat/windows/makedef
index add8222d13..af42f08fd5 100755
--- a/compat/windows/makedef
+++ b/compat/windows/makedef
@@ -48,7 +48,13 @@ trap 'rm -f -- $libname' EXIT
 if [ -n "$AR" ]; then
     $AR rcs ${libname} $@ >/dev/null
 else
-    lib.exe -out:${libname} $@ >/dev/null
+    machine_flag=""
+    case "$LDFLAGS" in
+    *"machine:arm64ec"*)
+        machine_flag="-machine:arm64ec"
+        ;;
+    esac
+    lib.exe ${machine_flag} -out:${libname} $@ >/dev/null
 fi
 if [ $? != 0 ]; then
     echo "Could not create temporary library." >&2
@@ -106,12 +112,21 @@ if [ -n "$NM" ]; then
               grep -v : |
               grep -v ^$ |
               cut -d' ' -f3 |
-              sed -e "s/^${prefix}//")
+              sed -e "s/^${prefix}//" -e "s/^#//" |
+              grep -v '\$entry_thunk' |
+              grep -v '\$exit_thunk')
 else
-    dump=$(dumpbin.exe -linkermember:1 ${libname} |
-              sed -e '/public symbols/,$!d' -e '/^ \{1,\}Summary/,$d' -e "s/ \{1,\}${prefix}/ /" -e 's/ \{1,\}/ /g' |
+    member=1
+    case "$LDFLAGS" in
+    *"machine:arm64ec"*)
+        member=32
+        ;;
+    esac
+    dump=$(dumpbin.exe -linkermember:${member} ${libname} |
+              sed -e '/public symbols/,$!d' -e '/^ \{1,\}Summary/,$d' -e 's/^[[:space:]]*[0-9A-Fa-f]\{1,\}[[:space:]]\{1,\}//' -e "s/^${prefix}//" -e 's/^#//' |
               tail -n +2 |
-              cut -d' ' -f3)
+              grep -v '\$entry_thunk' |
+              grep -v '\$exit_thunk')
 fi
 
 rm ${libname}
diff --git a/configure b/configure
index 39e69d217d..db18aa2c28 100755
--- a/configure
+++ b/configure
@@ -6079,7 +6079,7 @@ case $target_os in
         SLIBSUF=".dll"
         SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
         SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
-        SLIB_CREATE_DEF_CMD='EXTERN_PREFIX="$(EXTERN_PREFIX)" $(SRC_PATH)/compat/windows/makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)'
+        SLIB_CREATE_DEF_CMD='LDFLAGS="$(LDFLAGS)" EXTERN_PREFIX="$(EXTERN_PREFIX)" $(SRC_PATH)/compat/windows/makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)'
         SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
         SLIB_INSTALL_LINKS=
         SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
-- 
2.43.0


[-- Attachment #3: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Harish Raja Selvan via ffmpeg-devel]

Hi Martin,

Thanks for the cleanups and explanations!

I’ve tested your fixed-up version and it works as expected.

Looks good to me.
Regards,
Harish Raja Selvan.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Rémi Denis-Courmont via ffmpeg-devel]

	Hello,

Le keskiviikkona 22. lokakuuta 2025, 7.33.31 Itä-Euroopan kesäaika Harish Raja 
Selvan via ffmpeg-devel a écrit :
> This patch adds support for ARM64EC builds on Windows by updating .def file
> generation logic for shared libraries and ensuring the correct machine flag
> is passed to lib.exe and dumpbin.exe.

This would be fine as a draft PR but that's just the tip of the iceberg.

If you want to compile AArch64 FFmpeg for use in emulated x86 processes, then 
you need a FFmpeg that exposes the same ABI as the x86 FFmpeg. That's going to 
require a lot of changes throughout the code base (and I doubt people here 
will agree to them overall).

And then an FFmpeg that would work both in x86 emulation and in native AArch64 
is just a pipe dream, since they have conflicting ABIs.

-- 
ヅニ-クーモン・レミ
Villeneuve de Tapiola, ex-République finlandaise d´Uusimaa



_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

On Wed, 22 Oct 2025, Rémi Denis-Courmont via ffmpeg-devel wrote:

> If you want to compile AArch64 FFmpeg for use in emulated x86 processes, 
> then you need a FFmpeg that exposes the same ABI as the x86 FFmpeg. 
> That's going to require a lot of changes throughout the code base (and I 
> doubt people here will agree to them overall).

Can you elaborate on what changes you think would be needed?

The compilers (both MSVC and Clang) in arm64ec mode produce code that is 
ABI compatible with x86_64 code - that's part of the whole point of it. It 
is by default ABI compatible without us doing anything about it.

In arm64ec mode, the compiler defines __x86_64__ (or _M_X64) and does not 
define __aarch64__ (or _M_ARM64). It does define __arm64ec__ (or 
_M_ARM64EC) to distinguish it from regular x86_64 though.


There are a few corner cases though; e.g. the cpuflags exposed by 
av_get_cpu_flags() in an arm64ec build would be arm64 flags, while they 
would be x86_64 flags in an x86_64 build.


As a concrete example, I did fully stock x86_64 and arm64ec builds, with 
both MSVC and mingw tools. I took ffmpeg.exe from the x86_64 build and the 
DLLs from the arm64ec builds, and they ran just fine together. (ffmpeg 
does warn that they are from builds with differing configure lines 
though.) Mixing e.g. an x86_64 avcodec DLL with an arm64ec avutil DLL 
doesn't work though.

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Rémi Denis-Courmont via ffmpeg-devel]

Le 23 octobre 2025 00:01:55 GMT+03:00, "Martin Storsjö" <martin@martin.st> a écrit :
>On Wed, 22 Oct 2025, Rémi Denis-Courmont via ffmpeg-devel wrote:
>
>> If you want to compile AArch64 FFmpeg for use in emulated x86 processes, then you need a FFmpeg that exposes the same ABI as the x86 FFmpeg. That's going to require a lot of changes throughout the code base (and I doubt people here will agree to them overall).
>
>Can you elaborate on what changes you think would be needed?

You're supposed to expose the same binary interface as x86. This is obviously not working correctly for CPU flags, which *are* part of the public libavutil interface, AFAIK.

I don't know what else won't work and I'm not going to audit the code.

>In arm64ec mode, the compiler defines __x86_64__ (or _M_X64) and does not define __aarch64__ (or _M_ARM64). It does define __arm64ec__ (or _M_ARM64EC) to distinguish it from regular x86_64 though.

Yes, and it seems extremely unlikely that that would just work. Any inline x86 assembler could break. And even if that did work, it would lack all Arm assembler optimisation so it would likely be worst than just using x86 FFmpeg and passing it through the JIT.

I guess that the code is instead compiled as normal AArch64 just with a different ABI, but then that doesn't work either as noted above.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

On Thu, 23 Oct 2025, Rémi Denis-Courmont via ffmpeg-devel wrote:

>
>
> Le 23 octobre 2025 00:01:55 GMT+03:00, "Martin Storsjö" <martin@martin.st> a écrit :
>> On Wed, 22 Oct 2025, Rémi Denis-Courmont via ffmpeg-devel wrote:
>>
>>> If you want to compile AArch64 FFmpeg for use in emulated x86 processes, then you need a FFmpeg that exposes the same ABI as the x86 FFmpeg. That's going to require a lot of changes throughout the code base (and I doubt people here will agree to them overall).
>>
>> Can you elaborate on what changes you think would be needed?
>
> You're supposed to expose the same binary interface as x86. This is 
> obviously not working correctly for CPU flags, which *are* part of the 
> public libavutil interface, AFAIK.

Yes - although most users of the DLLs won't touch these, so as long as all 
the libav* DLLs are built in the same form, this won't matter.

> I don't know what else won't work and I'm not going to audit the code.
>
>> In arm64ec mode, the compiler defines __x86_64__ (or _M_X64) and does 
>> not define __aarch64__ (or _M_ARM64). It does define __arm64ec__ (or 
>> _M_ARM64EC) to distinguish it from regular x86_64 though.
>
> Yes, and it seems extremely unlikely that that would just work. Any 
> inline x86 assembler could break. And even if that did work, it would 
> lack all Arm assembler optimisation so it would likely be worst than 
> just using x86 FFmpeg and passing it through the JIT.
>
> I guess that the code is instead compiled as normal AArch64 just with a 
> different ABI, but then that doesn't work either as noted above.

Yes, it's built with ARCH_AARCH64 within ffmpeg, so it doesn't see the 
inline x86 assembler - and uses the aarch64 assembly.

Anyway, you're right that there are potential subtle ABI inconsistencies 
in this build mode. But it also practically seems to work fine. It's 
not a setup that I would go out and vouch support for - but for people 
willing to build it, it seems to practically be usable - without any 
further patches.

Offhand, I don't foresee any more patches being needed here (and Harish 
can maybe chime in if you had any more patches in your pipeline for this 
build mode?), other than potential minor build system tweaks. (The patch 
for makedef being discussed here seems ok to me, and I'll merge it soon.)

If other patches were to be suggested, that would be more invasive and 
affect maintainability, I agree that we should push back against including 
it. But these build system fixes seem fine.

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Rémi Denis-Courmont via ffmpeg-devel]

Le 23 octobre 2025 09:31:26 GMT+03:00, "Martin Storsjö via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org> a écrit :
>On Thu, 23 Oct 2025, Rémi Denis-Courmont via ffmpeg-devel wrote:
>
>> 
>> 
>> Le 23 octobre 2025 00:01:55 GMT+03:00, "Martin Storsjö" <martin@martin.st> a écrit :
>>> On Wed, 22 Oct 2025, Rémi Denis-Courmont via ffmpeg-devel wrote:
>>> 
>>>> If you want to compile AArch64 FFmpeg for use in emulated x86 processes, then you need a FFmpeg that exposes the same ABI as the x86 FFmpeg. That's going to require a lot of changes throughout the code base (and I doubt people here will agree to them overall).
>>> 
>>> Can you elaborate on what changes you think would be needed?
>> 
>> You're supposed to expose the same binary interface as x86. This is obviously not working correctly for CPU flags, which *are* part of the public libavutil interface, AFAIK.
>
>Yes - although most users of the DLLs won't touch these, so as long as all the libav* DLLs are built in the same form, this won't matter.

I disagree. That's literally a known bug.

And even then, that's only the most obvious issue. It does not seem like anyone has made any serious review/audit of the external interfaces, for things like conditionals, alignment or size mismatches, etc.

If MCW is happy with this kludge, then they can use it on their own. I don't think upstream should merge half-baked stuff though.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Rémi Denis-Courmont via ffmpeg-devel]

-1 for not addressing any of my earlier comments.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Rémi Denis-Courmont via ffmpeg-devel]

Hello,

Le maanantaina 22. syyskuuta 2025, 13.04.40 Itä-Euroopan kesäaika 
harish.rajaselvan--- via ffmpeg-devel a écrit :
> I'm reaching out regarding ARM64EC support for FFmpeg on Windows.

I don't really see the point. There is no use case for FFmpeg proper (the 
executable) to target ARM64EC, and the use care for libav.* seem flimsy at 
best.

To make matters worse, this would really only serve proprietary software. 
Open-source software should, and most likely can, be recompiled to the normal 
Windows/UEFI variant of the AArch64 ABI. If this was a simple question of 
tweaking build parameters and some macros, that could be acceptable.

But this will constrain the assembler is aggravating. It probably requires 
major changes already, but even if it doesn't, I don't think we should 
constrain future assembler code nor expect developers to support the JIT-
friendly ABI.

> Additionally, I would like to know the point of contact for hosting ARM64EC
> binaries (for example, via btbn or gyan.dev), so that people targeting this
> platform can have access to FFmpeg builds for this target.

I don't think that the community resources should be spent on making those 
builds at all. It looks like that would only benefit proprietary Windows apps 
ISVs. That being the case, they should fund the CI setup and running 
themselves.

-- 
ヅニ-クーモン・レミ
Hagalund ny stad, f.d. Finska republik Nylands



_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

On Sat, 27 Sep 2025, Rémi Denis-Courmont via ffmpeg-devel wrote:

> But this will constrain the assembler is aggravating. It probably requires
> major changes already, but even if it doesn't, I don't think we should
> constrain future assembler code nor expect developers to support the JIT-
> friendly ABI.

This is indeed a core concern of mine as well.

I don't mind adding build system tweaks to make it possible to build, but 
having to modify all the assembly to make it properly compatible with 
arm64ec isn't really feasible or maintainable.

Given the information in your other mails, it sounds like you don't make 
any modifications to the aarch64 assembly at all - so it uses all the 
aarch64 registers, including the ones that are disallowed to use in 
arm64ec mode.

If building with MSVC with the suggested configuration, building produces 
a very large number of warnings of this kind:

Z:\home\martin\code\ffmpeg-msvc-arm64ec\libavutil\aarch64\float_dsp_neon.o.asm(1056) 
: warning A4253: this instruction uses forbidden registers
         fmul            v16.4s, v0.4s,  v4.4s

The same also is produced if building with Clang:

src/libavutil/aarch64/float_dsp_neon.S:32:9: warning: register Q16 is 
disallowed on ARM64EC.
         fmul v16.4s, v0.4s, v4.4s
         ^

I've tried to talk to acquaintances to figure out exactly what one can 
expect to work and what one can't expect to work, if using assembly 
routines with all registers in arm64ec mode.

First off, calling a C function, which turns out to be in x86_64 mode, 
will clobber those registers. But for assembly which only works as leaf 
functions, that don't call C functions (and those C functions are internal 
in ffmpeg, which also are in arm64ec mode, not x86_64), this shouldn't be 
happening.

Secondly, unwinding through such functions won't work correctly either. 
But we never provide any unwind info for assembly functions, and don't 
expect to unwind through them anyway, so that's probably not an issue 
either.

Inspecting (and possibly single-stepping through) such code in a debugger 
could break.

One case which really can break though, is if some other process suspends 
and resumes the thread - as a form of manual scheduling. This sounds 
exotic, but I'm told these things do exist.

All in all, it sounds to me like these things actually can work, at least 
with some amount of caveats. In that case, it sounds acceptable to add 
build system tweaks to make it buildable, as long as the assembly itself 
doesn't need compromises for this mode.

I tested a checkasm.exe built in this mode, both with MSVC and with Clang, 
and it seems to run fine in a single-shot test at least.

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Rémi Denis-Courmont via ffmpeg-devel]

Le 3 octobre 2025 15:44:56 GMT+03:00, "Martin Storsjö via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org> a écrit :
>First off, calling a C function, which turns out to be in x86_64 mode, will clobber those registers.

Will it? I thought code JITed from x86_64 to AArch64 could *not* access the reserved registers, and that was why they were forbidden (which barely makes sense to me).

I don't understand how this can be a problem except for green threads and long jumps. But that shouldn't be allowed to happen if you're using FFmpeg anyway - it could dead lock - regardless of the instruction set.

But again, the use case seems very unclear. I'm sure some people are using x86 FFmpeg on Arm, but how do you credibly end up with an AArch64 FFmpeg inside an Arm64EC process?

We shouldn't go out of our way to support an academic exercise or some weird proprietary insane code.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

On Fri, 3 Oct 2025, Rémi Denis-Courmont wrote:

> Le 3 octobre 2025 15:44:56 GMT+03:00, "Martin Storsjö via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org> a écrit :
>> First off, calling a C function, which turns out to be in x86_64 mode, 
>> will clobber those registers.
>
> Will it? I thought code JITed from x86_64 to AArch64 could *not* access 
> the reserved registers, and that was why they were forbidden (which 
> barely makes sense to me).

The JITed code itself probably doesn't don't use those registers, no, and 
probably not the JIT compiler itself either. I'm not entirely sure about 
which case actually would clobber them - but I'm told this is a case that 
can do it. Perhaps there's some serialization to/from CONTEXT in some of 
the transitions (perhaps when invoking the JIT compiler?).

> But again, the use case seems very unclear.

Requesting us to provide premade builds for this mode seems very unclear, 
yes - that sounds unreasonable to me.

Wanting to use the libav* libraries in a hybrid x86_64/arm64ec process 
seems like something quite plausible though. Not something I'd go out of 
my way to complicate other things to accomplish, but reasonable build 
system tweaks to allow such builds sound tolerable to me.

> I'm sure some people are using x86 FFmpeg on Arm, but how do you 
> credibly end up with an AArch64 FFmpeg inside an Arm64EC process?

I don't quite understand what you mean here. Do you mean how one does to 
end up with the aarch64 assembly touching all registers, in an arm64ec 
process? Or how one does to retrofit an aarch64 ffmpeg DLL into an arm64ec 
process?

For the former - it works just fine to build and assemble our current 
aarch64 assembly, unmodified, with both MSVC and LLVM build tools. Both of 
them complain loudly about code touching the unavailable registers, but it 
still builds fine, and runs fine in practice.

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Rémi Denis-Courmont via ffmpeg-devel]

Le perjantaina 3. lokakuuta 2025, 18.11.55 Itä-Euroopan kesäaika Martin 
Storsjö a écrit :
> Wanting to use the libav* libraries in a hybrid x86_64/arm64ec process
> seems like something quite plausible though. Not something I'd go out of
> my way to complicate other things to accomplish, but reasonable build
> system tweaks to allow such builds sound tolerable to me.

Is it that plausible? That seems far less plausible than running a plain 
x86_64 application on an Arm system. Especially for something performance 
sensitive as FFmpeg, you would want a proper native port. Sure, you could very 
well end up with slow x86 code due to "non-technical challenges" (euphemism 
for the vendor not providing an Arm build or your IT department lagging 
behind).

But realistically, you're not going to be able to replace an x86 
libavcodec.dll with an AArch64 libavcodec.dll in such an x86 app. The chance 
of finding the right build options to get a compatible ABI are pretty much 
zero. In fact, they are very exactly zero because the libavutil ABI depends on 
the ISA due notably to the CPU feature flags, configuration parameters, etc.

So this can only work if you have Arm64EC application code calling an 
hypothetical Arm64EC libav*, but also calling x86 code on independent code 
paths. Why would you not port the x86 code to Arm too (or run them in a 
separate process)? That seems pretty fringe if not academic to me.

-- 
Rémi Denis-Courmont
Hagalund ny stad, f.d. Finska republik Nylands



_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Stephen Hutchinson via ffmpeg-devel]

On 10/3/25 12:39 PM, Rémi Denis-Courmont via ffmpeg-devel wrote:
> Le perjantaina 3. lokakuuta 2025, 18.11.55 Itä-Euroopan kesäaika Martin
> Storsjö a écrit :
>> Wanting to use the libav* libraries in a hybrid x86_64/arm64ec process
>> seems like something quite plausible though. Not something I'd go out of
>> my way to complicate other things to accomplish, but reasonable build
>> system tweaks to allow such builds sound tolerable to me.
> 
> Is it that plausible? That seems far less plausible than running a plain
> x86_64 application on an Arm system. Especially for something performance
> sensitive as FFmpeg, you would want a proper native port. Sure, you could very
> well end up with slow x86 code due to "non-technical challenges" (euphemism
> for the vendor not providing an Arm build or your IT department lagging
> behind).
> 
> But realistically, you're not going to be able to replace an x86
> libavcodec.dll with an AArch64 libavcodec.dll in such an x86 app. The chance
> of finding the right build options to get a compatible ABI are pretty much
> zero. In fact, they are very exactly zero because the libavutil ABI depends on
> the ISA due notably to the CPU feature flags, configuration parameters, etc.
> 
> So this can only work if you have Arm64EC application code calling an
> hypothetical Arm64EC libav*, but also calling x86 code on independent code
> paths. Why would you not port the x86 code to Arm too (or run them in a
> separate process)? That seems pretty fringe if not academic to me.
> 

While I haven't gotten through adding the more newly-added external
libraries to the tedious mingw build guide, IIRC most/all of them
already can be built natively for AArch64, so I can't really think of a
publicly-available set of circumstances where someone would be linking
an x86-64 dependency into a native Arm instance of FFmpeg.

I could see it as trying to use x86-64 builds of AviSynth+, though.
That's LoadLibrary, and I either can't remember or haven't seen
anything that describes how the Arm64EC concept behaves when using
dynamic loading.

Yes, there is a native AArch64 Windows release of AviSynth+,
but there won't be one for Arm64EC, because we dropped support
for building with MSVC outside of x86(-64).  An llvm-mingw-built
Arm64EC core wouldn't be able to load MSVC-built x86-64 plugins.

So it wouldn't surprise me if people stubbornly refuse to use
the AArch64 release because they don't want to let go of a build
of a plugin that the plugin author only published for x86-64
(even if said plugin is FOSS).
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Rémi Denis-Courmont via ffmpeg-devel]

Le perjantaina 3. lokakuuta 2025, 23.49.46 Itä-Euroopan kesäaika Stephen 
Hutchinson via ffmpeg-devel a écrit :
> While I haven't gotten through adding the more newly-added external
> libraries to the tedious mingw build guide, IIRC most/all of them
> already can be built natively for AArch64, so I can't really think of a
> publicly-available set of circumstances where someone would be linking
> an x86-64 dependency into a native Arm instance of FFmpeg.
> 
> I could see it as trying to use x86-64 builds of AviSynth+, though.
> That's LoadLibrary, and I either can't remember or haven't seen
> anything that describes how the Arm64EC concept behaves when using
> dynamic loading.
> 
> Yes, there is a native AArch64 Windows release of AviSynth+,
> but there won't be one for Arm64EC, because we dropped support
> for building with MSVC outside of x86(-64).  An llvm-mingw-built
> Arm64EC core wouldn't be able to load MSVC-built x86-64 plugins.
> 
> So it wouldn't surprise me if people stubbornly refuse to use
> the AArch64 release because they don't want to let go of a build
> of a plugin that the plugin author only published for x86-64
> (even if said plugin is FOSS).

Ok, fair enough. Though on second thought, I think that the problem of how to 
build that is far worse than the problem of register allocations in assembler.

-- 
ヅニ-クーモン・レミ
Tapio's place new town, former Finnish Republic of Uusimaa



_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org