Date: Mon, 2 Aug 1999 13:11:42 +0300 (IDT) From: Eli Zaretskii 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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 if you use the above code.) Note that I didn't test the above, so it might contain bugs. Caveat emptor.