> Patrik Stridvall <psÉleissner.se> writes:
>
> > This is not what we want. Of course this is only a problem is the
> > WineLib application uses gs, which is not very likely in itself.
> > However it might use a Windows binary only dll that does...
>
> True; I guess the question becomes: are there really dlls out there
> that want to mess with %gs?
Probably, but I don't know of any, but then it is rather hard to
now if a dlls does without testing.
> > Of course doing it in a thunking layer as proposed by Ulrich (and I)
> > is not very cheap runtime wise, but it is obviously correct and much
> > more maintainable and the thunking layer is needed for running x86
> > binaries on non-x86 anyway.
>
> Saving/restoring %gs on nearly every function call is not an option.
It is only needed to be saved/restored on internal/external transitions.
Of course there are a lot of those when running under the emulator...
WineLib applications will be largely unaffected,
unless they uses gs themselves which is probable
very rare and should be fixed for portabillity
reason anyway.
> > In short we could do both as you and Ulrich (and I) proposed and
> > have compile time options and let the user decide between speed,
> > Windows API only and using things like OpenGL the needs pthreads.
>
> Then you distribute two versions of libwine, one that is slow as hell
> and one that is downright broken, but it's OK since the user has a
> choice? No thanks.
I wouldn't quite put it that way, but you have a point,
even though it is not a very convincing one.
Anyway if you look at my stdcall-thunking patch you will see
that the code doesn't touch the normal Wine source files
at all and the the use of thunks could be a made _runtime_ option
as well at a small runtime cost. Of course if you in runtime
decide to use it the cost is of course much higher...
I agree that is not the ideal approach but in order to
support applications that actually uses gs it is the
lest bad way I can think of.
BTW I just wonder how much the thunking overhead for
internal/external calls really is in average for
normal applications. I might be wrong but I should guess
just a few percent.
IIRC Linus Torsvalds once said that in the choice between
a obviously correct and maintainable but slower solution
and but less obviously correct and maintainable solution
he would choose the first solution. Why? Because of
Moore law (CPU speed double every 18 months IIRC)
it will not take many months before the overhead before
the introduced overhead is "eaten up" by faster CPU:s.
So even if the overhead is large it will be quickly
"easten up" by Moore's law. Also note that Wine is
largely run on desktop machines that has a mostly idle
CPU. Does a few percent or even tens of percent overhead
matter under those circumstances? It will only make
the CPU more idle. So what?
Beside most applications like MPEG (audio/video) player
that uses a lot of CPU will probably care less about
the overhead because of the expensive calculations
many function calls make.
In short if you don't like have a compile time option
make it runtime option, or even no option at all,
most user will not notice the overhead anyway.
PS. Yes, I know it introducies function call latency
as well but I don't think it will matter for 99.99%
of all applications either.
