[FFmpeg-devel] [libav-devel] [PATCH] x86inc: Avoid using eax/rax for storing the stack pointer

[Henrik Gramner]

On Mon, Dec 26, 2016 at 2:52 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
>  Hm, OK, I think it affects unix64/x86-32 also when using 32-byte
> alignment. We do use the stack pointer then.

On 32-bit and UNIX64 it simply uses a different caller-saved register
which doesn't require additional instructions.

> I think my hesitation comes from how I view x86inc.asm. There's two ways to
> see it:
> - it's a universal tool, like a compiler, to assist writing assembly
> (combined with yasm/nasm as actual assembler);
> or
> - it's a local tool for ffmpeg/libav/x26[5], like libavutil/attributes.h,
> to assist writing assembly.

In practice it's basically (a), but designed around the use-case of (b).

> If x86inc.asm were like a compiler, every micro-optimization, no matter the
> benefit, would be important. If it were a local tool, we indeed wouldn't
> care because ffmpeg spends most runtime for important use cases in other
> areas. (There's obviously a grayscale in this black/white range that I'm
> drawing out.) So having said that, patch is OK. If someone would later come
> in to add something to take return value type (void vs. non-void) into
> account, I would still find that helpful. :)

Specifying a full function prototype for cglobal instead of the
current implementation would be ideal. It would also allow stuff like
full floating-point abstraction and the ability to auto-load a
non-contiguous subset of parameters with optional sign-extension of
32-bit args etc.

The problem is that it's difficult to implement in a clean way with
the limited Yasm syntax. Nasm does have better string parsing
capabilities (although I haven't looked into it in detail) so if we
decide to drop Yasm support at some point in the future this feature
could perhaps be considered.