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?
> gcc 2.95 asm or disabele it and as disscussed will cause many other issues
The only one of the "many other issues" you claimed that had anything to
do with reality was different flags for asm files, and that ONLY if you
want to support mostly-but-not-really-PIC code like now generated with
-fPIC and MANGLE on x86. You clipped the part of my post which
questioned the usefulness of that.
> So while you can continue to claim that there would be some so far unmentioned
> advanatge in your approch (we really are arguing about how bad its
> disadvantages are)
It's actually correct code whereas MANGLE relies on implementation
details of the compiler especially for static variables. Using named asm
args gives better maintainability (will you seriously try to argue that
naming variables "var0, var1, var2, var3, var4, var5, var6", and
requiring them to be renamed whenever one is added/removed/moved, is
equally maintainable?).
> 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.