delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/07/16/10:30:46

Xref: news2.mv.net comp.os.msdos.djgpp:6051
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Locking RAM for hardware interrupts
Date: Tue, 16 Jul 1996 08:15:51 CDT
Organization: Rice University, Houston, Texas
Lines: 15
Message-ID: <31eb9607.sandmann@clio.rice.edu>
References: <Pine DOT SOL DOT 3 DOT 91 DOT 960715180219 DOT 9688B-100000 AT zveris>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: clio.rice.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

>   you could just enable near pointers, do your stuff and then disable them.
>   However, this is slow, because __djgpp_nearptr.. functions issue DPMI calls

The expectation was that you would not call these routines so many times as
to hurt the performance in production code.  Once the code is debugged,
turn off the extra calls.

>   etc. I found a cool workaround for that:
>   [1] Allocate an alias to your data descriptor and set its limit to 4GB.
>   [2] When you need near pointers, load ds and es with the alias.
>   [3] When done reload ds and es with the original selector.

This is a very nice setup.  Beware that sbrk() messes with limits, so if
you call malloc() or any routine that does, you might not get exactly
what you expect.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019