From:	Geza Herman <geza AT inf DOT bme DOT hu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Getting the fastest running
Date:	Mon, 5 Jan 1998 13:48:57 +0100
Organization:	Technical University of Budapest
Lines:	63
Message-ID:	<Pine.GSO.3.95.980105133623.26896A-100000@kempelen.inf.bme.hu>
References:	<1998918057C AT fs2 DOT mt DOT umist DOT ac DOT uk>
NNTP-Posting-Host:	kempelen.inf.bme.hu
Mime-Version:	1.0
In-Reply-To:	<1998918057C@fs2.mt.umist.ac.uk>
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

On Mon, 5 Jan 1998, Anthony.Appleyard wrote:


>   (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?
Why must you copying? You can write directly to vid.mem. Dosmemput is very
fast, but you can make the copying a LITTLE bit faster( examine the
assembly code of dosmemput )


>   (1) In djgpp v2 how fast are farpokeb() / farpeekb() compared to directly
> writing to / accessing ordinary char variables?
A little bit slower because of the selector registers. You can use
_farsetsel, and _farnspokeb( if I remember the names right )

>   (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?
DPMI and EMS are two different worlds. DPMI sees the memory as a whole, it
doesn't see XMS and EMS( for example: if your machine has 16MB of mem, and
you use 5MB EMS, DPMI will see only 10MB ). There is no swapping.

>   (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.
Look (2)


>   (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)?
Why do you need it now?


>   (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?
No hidden interrupt routines. Generally, video memory is slower than
ordinary memory. Your video card handles 0xa0000 memory.

>   (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.

Real mode isn't the future. You'd better not use it. However, you can you
the older versions of Borland/Turbo C( version 3.0 )

To achieve the fastest running, (in DJGPP) use -O3.

Regards, 
Geza

- Raw text -