From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: DJGPP Asm problems Date: 15 Jun 2001 10:09:42 GMT Organization: Aachen University of Technology (RWTH) Lines: 58 Message-ID: <9gcmt6$7jr$1@nets3.rz.RWTH-Aachen.DE> References: <3B281DE4 DOT 6D242A5A AT QhaSecurity DOT com> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 992599782 7803 137.226.32.75 (15 Jun 2001 10:09:42 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 15 Jun 2001 10:09:42 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com birkoss wrote: > I create some function in Asm, ... and making your own life harder than it has to be, doing so. Unlike some other DOS compilers, DJGPP doesn't force you to use assembly whenever you want anything done efficiently --- it's clever enough to be quite efficient if you just let it do a decent job, and don't get into its way too much. > void full_screen() > { > __asm__ volatile(" > pushl %eax\n > movb $00,%ah\n > movb $12,%al\n > int $0x10\n > popl %eax\n"); > } As Eli already pointed out: Calling __dpmi_int() would have been a lot easier, here. > void point(int x_p, int y_p, int couleur_p) > { > __asm__ volatile(" > pushl %%eax\n > pushl %%ecx\n > pushl %%edx > movl %0,%%eax\n > movl %1,%%ecx\n > movl %2,%%edx\n > movb $0x0C,%%ah\n > int $0x10\n > popl %%edx\n > popl %%ecx\n > popl %%eax\n" > : > : "a" (couleur_p), "c" (x_p), "d" (y_p) And this one is outright wrong, I think. You're mixing up extended assembly (using input register descriptors) with simple assembly ("volatile" qualifier, and pushing all registers yourself). And this, too, could have been done using __dpmi_int, instead. Not even to mention that calling a BIOS interrupt to put a pixel to screen is almost never a good idea. Not in plain 16bit DOS programs, and even less so in 32bit protected mode ones made by DJGPP, which have to do all kinds of magic behind the scenes to be able to call 16bit BIOS interrupts. Directly accessing the framebuffer is going to be a lot faster than any code similar to the above. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.