Mail Archives: djgpp/2001/01/18/10:17:36
In article <Pine DOT LNX DOT 3 DOT 96 DOT 1010118122624 DOT 30111C-100000 AT winnie DOT obuda DOT kando DOT hu>,
Kovacs Viktor Peter <vps AT winnie DOT obuda DOT kando DOT hu> wrote:
> > Contents:
> > - Fastest possible way to draw pixel=B4s (well, maybe the near pointer ha=
> ck
> > mentioned in DJGPP FAQ is faster :)). Drawing developed as a macro (becou=
> rse
> > jumping to function and back again takes more time than drawing the damn
> > pixel !). Screen coordinates pre-calculated in the global table.
> >=20
> > Feedback needed about the following subjects:
> > 1) Is it necessary to save ES segment register (the macro currently does =
> not
> > do it, but it seems to work fine, no crashes, etc...) ?
> > 2) Is the assembly command "les %0,%%edi" faster than the currently us=
> ed
> > "movw %0,%%es;movl %1,%%edi" pair ?
>
> Have you heard about the far ptr hack in djgpp? It even allows loading
> the segment outside a tight loop...
> (It was designed to work with systems that don't allow segment limits
> to be set to 4GB.)
> =20
> About your questions:
> -yes, you should save ES, because someone (memcpy) might use it...
> -les: On the P4 it is slower, on other systems it is about the same
> -precalculated tables: when you use integer math only, it is faster to
> calculate it on the fly, because you can spare a few TLB and cache
> entries with it (the overall speed will be faster)
> -tables are to be used instead of float math...
In general precalculated tables are only good if you have to perform integer
division. In my Plush3D library when I calculated Alphablending via a huge
table lookup instead of integer arithmetic I sped it up by about 35% despite
the 256kb table I had to use.
e.g if the operation takes more then 5 or so cycles to calc use a table
assuming it is possible.
Athlons like tables :-)
Tom
Sent via Deja.com
http://www.deja.com/
- Raw text -