From:	"Anthony.Appleyard" <MCLSSAA2 AT fs2 DOT mt DOT umist DOT ac DOT uk>
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>

  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.

- Raw text -