[FFmpeg-devel] Nasm/yasm support and x264 asm

[Michael Niedermayer]

On Mon, Jul 28, 2008 at 10:41:10PM -0600, Jason Garrett-Glaser wrote:
> > 1. discuss/agree on where to put the code (x264 + lavc, x264, lavc, new lib)
> 
> This is a significant issue; it may not be easy to share the code
> directly both for practicality reasons and because the code will need
> to be modified significantly.  

With the "practicality reasons" i surely agree.

But "modified significantly" is a problem independant of the details of
sharing because if it cannot be avoided, future maintaince could be annoying.
We definitly should aim toward having both x264 & lavc use the same files
(in the md5 checksum matches sense). That way any changes done on one project
could be trivially ported to the other.


> On the other hand, there's still
> improvements going into the asm all the time (especially from holger,
> one of our SOC students), so copy-pasting the asm would make it more
> difficult to maintain.
> 
> ffmpeg would probably want to adopt x264's "nasm-based" syntax--that
> is, its combinations of macros for doing the following:
> 
> 1.  Automatic abstraction between 32-bit and 64-bit
> 2.  Automatic abstraction between MMX and SSE
> 3.  Automatic handling of macros that permute their arguments
> 4.  Automatic handling of stack offsets, required for 1)

My intent was always to share the code so both sides are identical, that
also implicates using the macros.
This of course does no mean i would accept any code using some of these
macros in ffmpeg that has nothing to do with x264. OTOH it also doesnt
mean i would blindly reject code unrelated to x264 that uses some of
these macros ...

One thing for example that i would not accept in unshared code is
the numbered registers, the registers have names and hiding them behind
numbers is idiotic. using new names for the native 32/64 bit size makes
sense but they should be based on the historic names of the registers.
nax, nbx, ... would be a random option
If one would rename the registers per function so the code would be
more readable and use thing like src, dst, stride, ... that would be
nice but changing eax/ebx/... to r0/r1/... really is not, unless for the
occasional case where a r0 really maps to different physical registers
at different points in a function but in that case it almost certainly
should have some more descriptive name ...

but again, this is just for the case of new code submitted that is
unrelated to x264. Theres no sense in changing these and wasting time
to maintain such difference for code shared between x264&lavc.

So i think porting the code should be rather trivial ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080729/b10350d4/attachment.pgp>