Date:	Mon, 2 Aug 1999 13:11:42 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp AT delorie DOT com
Subject:	Re: Intel - AT&T inline with DJGPP
In-Reply-To:	<7o1psl$d46$1@news.iinet.net.au>
Message-ID:	<Pine.SUN.3.91.990802131044.4488F-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 1 Aug 1999, Centrozity wrote:

> void putpixel(int x, int y, char col)
> {
>   asm{
>     mov ax,0a000h       //ax = segment adress of the screen
>     mov es,ax   //es = A000h
>     mov bx,y    //bx = y
>     mov di,bx   //di = y
>     xchg bh,bl  //bx = 256*y
>     shl di,6    //di = 64*y
>     add di,bx   //di = (256 + 64)*y = 320*y
>     add di,x    //di = 320*y + x
>     mov al, col //move the colorbyte to al
>     mov [es:di],al      // and move it to the screen
>   }
> }

Why do you need to torture yourself with assembly?  As far as I could
see, the same effect will be achieved with the following 1-liner:

     void __inline__ putpixel (int x, int y, unsigned char col)
     {
       _farpokeb (_dos_ds, 0xa0000 + 320*y + x, col);
     }

When compiled with optimizations (-O2 switch to gcc), `_farpokeb'
expands to fast inline assembly, and I made the whole function inline
to avoid the call overhead (or you can use a #define).  If you compile
with "-O2 -S" and look at the generated assembly, you will be
surprised by the quality of the code emitted by the compiler.

(Dont't forget to #include <sys/farptr.h> if you use the above code.)

Note that I didn't test the above, so it might contain bugs.  Caveat 
emptor.

- Raw text -