Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: "Elias Pschernig" <f DOT x DOT gruber-museum-arnsdorf AT magnet DOT at>,
        djgpp AT delorie DOT com
From: Nate Eldredge <nate AT cartsys DOT com>
Subject: Re: pointers under DJGPP
Date: Tue, 28 Apr 1998 20:37:54 -0700
Message-ID: <19980429033703.AAM3301@ppp104.cartsys.com>
Precedence: bulk

At 09:09  4/27/1998 +0200, Elias Pschernig wrote:

>thanks for your info
>
>i think -because of dpmi- i'll not try to use absolute addresses any longer,
>this seems to be no good idea...
>but whats with "djgpp_nearptr_enable" ?

Okay, I'll try to explain it. A so-called near pointer has exactly the same
structure as any other pointer; it is relative to the program's DS segment.
However, when you use `__djgpp_nearptr_enable', it changes the limit of the
DS segment (beyond which memory may not be accessed) so that it *wraps
around* the entire address space. At that point, all of memory is accessible
as an offset from the DS segment base.

>the .inf-files dont say very much about it, and my experience was that
>paging and virtual mem and all this is very slow, too slow for my sort
>of programs at least, so i use the near pointers, for things like copying
>memory to videoram...

That isn't true. The paging mechanisms are *always* used by the CPU,
regardless of whether you use "near" or "far" pointers. Overhead only occurs
when you touch a page which is not actually present and must be loaded from
disk. But that can only apply to memory inside your program's space (i.e.
normal C objects and `malloc' space), since that is all the DPMI server is
allowed to swap out. That also has no bearing on the near/far issue. Try it
and see. If your graphics work is primarily blitting, use `dosmemput', and I
doubt you'll see a performance drop.


Nate Eldredge
nate AT cartsys DOT com