[FFmpeg-devel] r9017 breaks WMA decoding on Intel Macs
Fri Jun 1 02:30:16 CEST 2007
On Fri, 1 Jun 2007, Michael Niedermayer wrote:
> On Thu, May 31, 2007 at 03:39:43PM -0700, Trent Piepho wrote:
> > > to summarize the possible solutions
> > > 1. dont support ancient assemblers
> > > 2. use 123%4 notation (most incorrect syntax possible, and will silently
> > > generate wrong code on all assemblers if you are unlucky)
> > > 3. add more "m" operands to avoid the offsets (might be slower, and might
> > > fail on some gcc versions)
> > "might"
> yes might ...
And the current incorrect syntax "might" break with future gas.
> > > 4. write the whole loop in asm
> > >
> > > note, ALL solutions need a "memory" clobber (or some other nasty tricks)
> > If you cast the operands through a struct that's 64-bits/128-bits as
> > apporpriate then you don't need to memory clobber.
> = nasty tricks ...
> also these can be done with the current controversal 123+%4 code as well
One could also call the "123+%4" syntax a nasty trick. After all, it is
incorrect according to the specification and is known to break on older
versions of gas and might not work with newer ones.
What is it exactly that makes passing memory operands that are the right
size a "nasty trick"?
> so i think you will agree with me that gcc does not gain any knowledge
> of the read/written memory locatons by introducing extra operands in this
> case ...
> and in the case that you agree we are back to the original:
> current code (breaks old buggy apple assembler) vs. more operands which might
And uses incorrect syntax.
> break with old gcc vs. writing the loop in asm which will be faster,
> more compatible and wont depend on the moon phases when gcc was
I think you'll find writing that loop in asm to not be so easy. You'll
need to have a lot of operands to the asm block, and that might break with
old gcc. And since it "might" break with old gcc it's impossible to do it.
More information about the ffmpeg-devel