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

Michael Niedermayer michaelni
Mon Jan 28 14:36:14 CET 2008

On Mon, Jan 28, 2008 at 02:30:05AM +0200, Uoti Urpala wrote:
> On Mon, 2008-01-28 at 00:22 +0100, Michael Niedermayer wrote:
> > On Mon, Jan 28, 2008 at 12:26:06AM +0200, Uoti Urpala wrote:
> > > On Sun, 2008-01-27 at 22:37 +0100, Michael Niedermayer wrote:
> > > > to proof the time, it needs to implement it, one would have to implement it.
> > > > As noone will implement your idea (not even you) one can only speculate
> > > > how long it would have taken.
> > > 
> > > It doesn't take much speculation to see your claim was wrong.
> > 
> > it takes less specuation to see it was correct
> You're being deliberately stupid. Even if it took as much per variable
> as making the cabac.h changes (which were doing much more that just
> removing the need for attribute_used) it still wouldn't take anywhere
> near the time you claimed.
> Can't you just admit your claim was bullshit? Continuing to argue when
> you're so obviously wrong is stupid.
> > but either way certain is that you belive it takes enough time that you wont 
> > implement it and rather point at a half working sketch you
> > did with a single small file (cabac.h)
> "small" file but one which uses nontrivial asm arguments, and
> demonstrates almost everything that would be needed in any other file.
> > also above all reimars solution is simple and allows asm to compile with
> > both gcc 2.95 and ICC your solution (which noone will implement not even you
> > due to the speculative amount of time it would require) will certainly break
> I don't plan to implement it because it doesn't look like it would be
> used in FFmpeg and I'm not interested in maintaining a fork, as I
> already told you.
> Can't you just admit your claims about time required for implementation
> were bullshit and stop trying to support them with insinuations like
> "due to the speculative amount of time it would require" when you run
> out of arguments?

when i made the claim i thought that you planned to remove all MANGLE()
no matter if it was needed for ICC, you later clarified this to only
some MANGLE() but kept using arguments (like maintainability, or that
it would be cleaner not to use MANGLE) in how far these apply if only
a part of them gets changed is debateable
either way, my claim is not bullshit when one considers all MANGLE() and
an average developer
if one considers just changeing some (which indeed is a little odd) it would
be proportionally less, also a determined developer would need less time than
an average one still it would be 100-1000x more time than reimars solution for
an equally determined developer
and i emphasize again this is for WORKING code, code which is disabled for
some supported compilers does not qualify as WORKING. You can as well disable
it for ICC

> > at that point the discussions about it are becoming a little to hypthotetical
> > for me, so feel free to continue this
> > but i fear it will be a monologue
> So you're saying that the discussion is hypothetical because you won't
> have any such changes in FFmpeg anyway, and then imply that the changes
> are not worth discussing (and your decision not to have them correct)
> because the discussion is just hypothetical.
> You were the one who started making claims about how the kind of asm I
> talked about would be impractical to implement or would not work in
> practice. It was no less "hypothetical" at that point. Now when you fail
> to substantiate your claims you suddenly find the "hypotheticality" a
> reason to drop the subject.

its hypothetical because noone will implement it
theres no sense in discussing a "patch" which will never be written


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- 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/20080128/d03ed24b/attachment.pgp>

More information about the ffmpeg-devel mailing list