X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Date: Fri, 4 Mar 2005 10:49:47 -0500
Message-Id: <200503041549.j24FnlGb005248@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp AT delorie DOT com
In-reply-to: <1109949195.480836.311620@f14g2000cwb.googlegroups.com>
	(ahmadwaris AT hotmail DOT com)
Subject: Re: dosmemput and dosmemget
References: <1109872127 DOT 199181 DOT 31850 AT l41g2000cwc DOT googlegroups DOT com>
   <01c5208e$Blat.v2.4$1141d8a0 AT zahav DOT net DOT il>
   <1109947854 DOT 819298 DOT 62120 AT l41g2000cwc DOT googlegroups DOT com> <1109949195 DOT 480836 DOT 311620 AT f14g2000cwb DOT googlegroups DOT com>
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> packet needs to increase by one after each IO. I do the increment in
> conventional memory, and then transfer the packet to DOS using
> dosmemput. After the IO is done, I read back to status of the IO by
> doing a dosmemget.

If you're storing the packet in conventional memory, you don't need
the dosmemput/dosmemget - the data is already in dos memory!  You can
at least use the <sys/farptr.h> inline functions to reduce the
overhead of dosmemget/dosmemput function calls.

The most efficient way to work with dos memory like that is to use
near pointers if you can (sys/nearptr.h).  This locks your application
in memory and computes the effective location of DOS memory (as a
regular 32-bit pointer), and you can then treat all of DOS memory just
like regular malloc'd memory.

Because it's locking your app, there are a few drawbacks - allocated
memory (via sbrk) isn't always contiguous, and the OS may not permit
it.