[Ffmpeg-devel] [BUG] Compilation failure when using --disable-opts

Måns Rullgård mans
Thu Mar 15 02:32:50 CET 2007


Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> On Thu, Mar 15, 2007 at 12:44:03AM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > Hi
>> >
>> > On Thu, Mar 15, 2007 at 12:13:07AM +0000, M?ns Rullg?rd wrote:
>> >> Michael Niedermayer <michaelni at gmx.at> writes:
>> >> 
>> >> > Hi
>> >> >
>> >> > On Wed, Mar 14, 2007 at 10:16:59PM +0000, M?ns Rullg?rd wrote:
>> >> >> Panagiotis Issaris <takis at issaris.org> writes:
>> >> > [...]
>> >> >> >> And are you certain that this is correct for x86_64?  Is
>> >> >> >> the check even needed there, what with all the extra
>> >> >> >> registers?
>> >> >> > Actually, I do not really know... I figured that because
>> >> >> > x86_64 is backwards compatible
>> >> >> 
>> >> >> The instruction set is compatible, meaning that everything
>> >> >> that works on 32-bit x86 still works on a 64-bit chip.
>> >> >> Things that don't work on 32-bit chips might still be
>> >> >> possible.  8 extra registers come to mind...
>> >> >> 
>> >> >> > the registers are still there and the tests should still
>> >> >> > work. In the worst case the tests would be unnecessary
>> >> >> > ofcourse... Prefer to remove it and only add it when
>> >> >> > someone figures out how this works on x86_64?
>> >> >> 
>> >> >> I don't think this is very urgent, so I'd rather wait a day
>> >> >> for someone with the knowledge to shed some light.
>> >> >
>> >> > the tests should be run on x86_64 too
>> >> 
>> >> Care to explain? 
>> >
>> > well if the x86 code is put under a CONFIG_EBX which is never set
>> > for x86_64 then you practically disable it for x86_64, not nice ...
>> 
>> What I meant was, is ebx ever reserved the same way on x86_64?  
>
> i dont know what gcc does with PIC on x86-64 maybe it doesnt reserve
> ebx/rbx after all theres no technical reason why it reserves it on
> x86-32 it could just handle the extra indirection over the GOT table
> like any other pointer dereference in C

Can you suggest some test we could do to find out?

>> With 8 more registers, it seem to me there should be enough for
>> both a frame pointer and whatever registers the inline asm needs.
>> Even if ebx is reserved, some other register could be used by the
>> assembler code.
>
> yes, of course but the existing asm code which has been written with
> x86-32 in mind uses ebx, why doesnt it ask gcc for any register with
> "r" well either because that was slower (see cabac code and ask gcc
> devels why) or because it lead to misscompiled code on some gcc
> versions or because the author was lazy

If ebx isn't available on x86_64, how about #defining something to ebx
on x86 and a free register on x86_64?  That would give the same code
as now on x86 and would work with any compiler options on x86_64.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list