Mail Archives: djgpp/1997/12/15/13:30:22
lturcott AT compuserve DOT com wrote:
>
> Hi Peter
>
> > using __djgpp_nearptr_enable and then use direct acces to videomem.
> > (SCREEN[offset]=col).
> >
> > put_pixel (int x,int y,unsigned char col)
> > {
> > asm ("
> > movw _dos_page,%%es (dos_page is preloaded with _dos_ds)
> > movl $0xa0000,%%edi
> > addl %%ebx,%%edi
> > stosb
> > :
> > :"a"(col),"b"((y<<8)+(y<<6)+x)
> > :"%eax,"%ebx",%edi"
> > }
> >
> > It this way of plotting a pixel the same as the farpokeb (...) version??
>
> Using __djgpp_nearptr_enable should be a bit faster because you avoid
> loading the ES register. But !..., It may not work from a DPMI server to
> an other.
If you use the 'no selector' versions of the _far* function you don't
have this load.
BTW this load takes more cycles than you may think because loading a
selector register involves loading a descriptor, checking access rights,
...
One advantage by using the near pointer versions is that the compiler
generates the code and that maybe further optimizations can be
performed. But do not expect too much from that. IMHO it is not worth it
using the near pointer functions. Now that I think of this, these
optimizations may even break your code, since accessing video memory is
always tricker than accessing 'normal' RAM. If the compiler manages to
combine two consecutive by writes into a single double-byte write, your
code may not work anymore. I do not know whether the gnu compiler is
intelligent enough at this time to do this, but I wouldn't be surprised
and eventually this optimization strategy may get in, and your code that
once ran perfectly won't run anymore after recompilation.
--
\ Vik /-_-_-_-_-_-_/
\___/ Heyndrickx /
\ /-_-_-_-_-_-_/
- Raw text -