[FFmpeg-devel] [RFC] replace some static with asm_visibility or?so

Måns Rullgård mans
Sat Feb 16 15:02:27 CET 2008

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> On 30 January 2008, M?ns Rullg?rd wrote:
>> > Patches that would fit my description would be for example Ian
>> > Caulfield's MLP decoder, some of Christophe Gisquet's optimizations,
>> > Siarhei Siamashka's arm idct optimizations (this also shows a double
>> > standard, because Mans - who has SVN commit rights - was free to
>> > commit suboptimal code, that has never been accepted from anybody
>> > without SVN commit rights - I must note however, that IMO it's good
>> > that Mans' code was made available early in SVN) or even my sparc
>> > idct optimizations - which eventually were comitted, but none of the
>> > others I have mentioned have been up to now (for quite some time).
>> The possible optimisations to the ARM IDCT are minor compared to the
>> improvement over the plain C version, and the code in SVN is clean.
> I would really appreciate if you benchmarked the code and shared the 
> results. My tests show that ARMv5TE optimized IDCT that I tried to submit 
> is quite competitive to your ARMv6 implementation and is even faster
> (because of the ARM write-allocate cache which is not typical for other
> architectures). With a minor patch that changes memory access pattern, 
> ARMv6 IDCT regains the leadership. I believe this all has been discussed 
> on the mailing list that time.

Right, I had confused some patches.  Guess it's time to put that
cross-compiler back into shape.

> Anyway, the showstopper was the alignment related code, namely stack
> realignment at runtime (in binaries, compiled for legacy OABI systems) 
> and the use of ".balign" directive (which is not supported by ancient 
> versions of binutils and requires hacks such as ASMALING macro for inline
> assembly in C sources).
> By the way, a few days ago I had a talk with some guy on #ffmpeg, he
> tries to build ffmpeg for iphone. Appears that Apple uses a
> version/fork of gnu assembler which is so ancient/broken, that it
> fails to compile virtually everything from 'libavcodec/armv4l'
> directory, even 'jrevdct_arm.S', which has not been touched for ages
> (for example, according to his information, '.word' directives need
> to be replaced with '.long', etc.). Naturally this version of
> assembler does not support '.balign' directive as well :)
> Well, some decision need to be done about it. Either we should try to 
> tweak code for better support of ancient toolchains (unless it really 
> requires too much efforts). Or is it up to Apple to fix their assembler? 
> Or investigate the possibility of using normal up to date version of 
> binutils when building ffmpeg for Apple devices.

It is, IMHO, quite acceptable for modern software to require modern
toolchains.  I see no sense in jumping through hoops only because
Apple are being silly.

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list