[XviD-devel] [CVS commit] Linux amd64 preliminary support

[Andrew Dunstan]

>Yeah that was the 64bit mov that was buggy.
>
>If you have a good idea how to support both the win64 and the linux
>function calling convention w/o duplicating code... don't hesitate.
>
>PS: i'm pretty sure that if  xvid 1.1 only supports linux 64bit, i'll be
>the target of thousands of flames like "linux elistism" and so on... i'd
>just say that  only people owning linux 64bit OSes  offered me a distant
>access  to develop  and do  all my  usual tests,  that's why  only linux
>support has  been merged, try to tell  that on forums if  you see people
>asking  why only  linux support  is completed  (except for  postproc and
>color conversion code, which are much more hard to port, at least the cc
>code).

I've thought about how to have support for both platforms in the .asm files 
and come up with two ideas. Depending on the platform add -DWIN64 or -DLINUX 
to the yasm command line, then:

Method 1 - Have seperate win64 and linux PROLOG (and EPILOG) macros for each 
function which move the function parameters into whatever registers the 
functions expect them to be in. Also push (and pop) any registers that must 
be preserved depending on the platform used.

Method 2 - Use macros to refer to the registers e.g. for win64 define 
parm1reg=rcx, for linux define parm1reg=rdi. Then throughout the function 
use the macros instead of the register names.

I think obviously method 1 would be less optimized but easier to code, 
method 2 would be (a lot) harder to work with but more optimal.

I can write a small example .asm file if you want to see what I mean, my 
explanations probably aren't very clear.

I've got two questions about the x64 work as it is now:
1. Why were the xvid_FIR_x_x_x_x tables moved into qpel_mmx.asm rather than 
qpel.c?
2. What's the problem with the color conversion code? I can't see why it was 
left out.