Mail Archives: djgpp/2000/03/02/16:21:02
Kalum Somaratna aka Grendel wrote:
> > How is rep movsd slow?
>
> It is not the rep movsd per se that is slow. But the setting up of the rep
> movsd (the seg regs etc..all those pushes and pops for the stack, so many
> arguments). If you have a time critial rountine I don't whink that
> movedata would be a good bet.
>
> > >Just imagine the overhead of setting up the stack 100 times etc during the
> > >100 calls to movedata in a interrupt handler :-)
> > So inline your movedata: set up the seg regs and then rep movsd
> > Isn't this what Allegro does?
>
> I think you may have misunderstood me here. Say there is a interrupt
> handler which is called 100 times per sec. And say that there is only one
> call to movedata in the interrupt handler. That would mean that a total of
> 100 calls to move data per sec. so imagine the overhead of setting up even
> the segregs repetetively.
>
> Since it is in the interest of getting a interrupt handler to finish
> execution as soon as possible I think that incorporating the movedata in
> to a time critical interrupt routine will result in unnecessary waste of
> the cpu. IMHO farpoke* would be a better alternative
But setting up the seg register (and the rest of the overhead of an inlined
movedata) isn't just there for show, and the farpoke* method must set up those
registers as well. There's no magic to farpoke*, the seg reg has to be set up
regardless of the method (with the exception of nearPtr stuff), so in most cases
farpoke* would be about the same (if optimizations are turned off), but I
suspect there are times when movedata would be better (when the optimizations
miss something).
--
(\/) Rolf Campbell (\/)
- Raw text -