Mail Archives: djgpp/1998/01/05/08:16:41
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 -