[FFmpeg-devel] r9017 breaks WMA decoding on Intel Macs
Sun Jun 3 23:55:16 CEST 2007
On Sun, Jun 03, 2007 at 09:37:37AM -0500, Graham Booker wrote:
> On Jun 2, 2007, at 11:13 PM, Loren Merritt wrote:
> >On Sat, 2 Jun 2007, Augie Fackler wrote:
> >>My solution is to do offset+0%number which translates to 345+0(%
> >>ebx,%ecx) or
> >>345+0123(%eax). In the first case, we add 0 which OS X's gas has
> >>no issue
> >>with and assembles correctly, and the second case, the number is
> >>given a
> >>leading 0, which is still the same number. I may be completely
> >>off my rocker
> >>here, but I expect this is the real solution for use. Attached is
> >>my patch
> >>to fix it.
> >123 != 0123
> >A leading 0 means octal.
> Arg!! Forgot about that. Well, I have another idea now, although it
> is a bit more hack like, but it seems to work.
> I noticed that the linux gas (newer gas really), upon seeing a (value
> operator "missing value"), assumes the "missing value" evaluates to
> 0. So, 123+(..) is changed to 123+0(...). The Mactel gas (older
> one) seems to assume that the evaluation of the operator is 0 (not
> the whole expression btw) meaning it evaluates to 0(..). So, what
> about offest+1*%number. The newer gas assumes offset+1*0(...) in the
> case of no offset in the %number, and the older gas assumes offset+0
> (...) in the same case. For both, if the %number contains an offset,
> then these evaluate to offset1+1*offset2(%register).
> More ugly, yes, but from what I can tell, this seems to work everywhere.
patch ok, if it does work ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel