From: "Anthony.Appleyard" Organization: Materials Science Centre To: DJGPP AT delorie DOT com Date: Mon, 5 Jan 1998 09:50:23 GMT Subject: Getting the fastest running Reply-to: Anthony DOT Appleyard AT umist DOT ac DOT uk Message-ID: <1998918057C@fs2.mt.umist.ac.uk> Precedence: bulk I have resubscribed to djgpp. I am developing a djgpp v2 PC program that makes moving graphics by often altering the screen display. To run faster it calls the DOS/VESA screen modes directly, rather than via djgpp graphic functions. The program runs OK; now I am trying to get it to run as fast as possible. I saved much time by doing noninteger arithmetic not in doubles but in long ints with the decimal point in the middle. I have done all I can in scavenging for scraps of time to save by e.g. declaring frequently accessed variables as `register', avoiding unnecessary testing, keeping multiplying and dividing out of inner loops. (0) Due to the nature of the work I must set up a screen display in an array and then bulk copy it to screen (in a 256-color mode: VESA 0x101, 0x103, 0x105, 0x107), by dosmemput()'ing it 0x10000 bytes at a time to the graphics screen address 0xa0000 etseq. Is this the fastest way to copy bulk matter to the graphics screen in djgpp? If not, what is? (1) In djgpp v2 how fast are farpokeb() / farpeekb() compared to directly writing to / accessing ordinary char variables? (2) When a PC program runs in protected mode with 32-byte addresses, when it accesses a variable (if it is not swopped out onto disk at the time), does it genuinely access extended memory directly?, or does it have hidden time overheads due to DPMI / EMS / XMS / etc interrupt routines swopping extended memory areas in and out of conventional memory so the program can access them? (3) A djgpp v2 program has an array of e.g. 1 to 4 megabytes. If I access or alter elements in it here and there at random rather than in sequence, am I thereby wasting much time making DPMI etc repeatedly swop memory segments about between conventional and extended memory? My PC has 16 megabytes of RAM. (4) If a program runs in real mode and accesses extended memory by directly calling the interrupt `AX=0x8700, int0x15' to swop memory segments between conventional memory and extended memory, could that program be safely called from Windows (3.1 or 3.1.1 or 95 or NT)? (5) If a program runs in real mode and accesses the graphics screen pixel values at address 0xa0000 etseq, is that access genuinely direct? Or is it via hidden interrupt routines which access the screen's RAM by reading and writing ports? Ditto re accessing the text screen? What is the speed of accessing screen RAM addresses compared to accessing ordinary RAM addresses? (6) What C or C++ compilers are there which compile into real mode? How to get them? I have `Small C', which compiles into real mode but as far as I can find only onto a .COM file, not an .EXE file. I have Borland C++ version 45 for Windows: it can compile for DOS or for Windows, but apparently always into protected mode.