[x264-devel] [RFC] [PATCH] x86inc add extended function declaration

[Loren Merritt]

On Thu, 31 Jan 2013, Matthias Räncker wrote:

> This is a patch to extend the existing functionality of declaring functions.
> The goal is to
> - provide a means to transfrom a function prototype given C into a function
>   declaration in asm.
> - give the assembler sufficient information about arguments so as to make
>   superfluous explicit movsxifnidn&co
> - aid debugging by checking assertions for function arguments on entry
>
> This is a draft, the code needs to be cleaned up a bit.
> Honestly though, that yasm preprocessor isn't very cooperative when it comes
> to writing code neatly...
>
> Comments/feature requests etc. welcome
>
> Signed-off-by: Matthias Räncker <theonetruecamper at gmx.de>
> ---
>  common/x86/test.asm   |    8 +
>  common/x86/x86inc.asm | 1002 ++++++++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 993 insertions(+), 17 deletions(-)
>  create mode 100644 common/x86/test.asm

So, I don't consider x32 to be very important. I said I'd accept a patch
for x86inc.asm iff it's both concise and not likely to require future
maintenance. And I'll accept a patch for x264 itself iff it doesn't
require keeping track of more things when writing individual asm
functions.

None of your added features is relevant to non-x32 code: intptr_t is
sufficient to avoid movsxd, I don't plan to rewrite everything with C
declarations, and assertions could go in the C version of a function. So
my review of this patch is: I don't think you're solving a real problem.

Likewise, if the simple version of your x86inc patch requires 267 lines of
movsxd sprinkled around the asm, then I'll reject the x264 part even if
the x86inc part is ok, and I'll promise not to test on x32 when adding
code to libav.

The obvious solution is to set all addressing modes to 32bit (if there's
a way to do that in yasm). I don't care if that would cost some address
size prefix bytes, the simplicity would be worth it.

--Loren Merritt