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 -- [email protected]
To unsubscribe send an email to [email protected]
