On Mon, Dec 26, 2016 at 2:52 PM, Ronald S. Bultje <rsbul...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
