Sender: nate AT cartsys DOT com
Message-ID: <37B50399.812B5F38@cartsys.com>
Date: Fri, 13 Aug 1999 22:50:17 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.11pre6 i586)
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: 0xA000 plot pixels questions in 13h mode
References: <Pine DOT WNT DOT 4 DOT 10 DOT 9908130817160 DOT 156-100000 AT mm58842-nt DOT mitre DOT org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

Goldberg,Neil R. wrote:
> 
> On Sun, 8 Aug 1999, Eli Zaretskii wrote:
> 
> >
> > On Thu, 5 Aug 1999, Neil Goldberg wrote:
> >
> > > Yes, _dos_ds is good for all _far* accesses. What I usually do is assign
> > > it to a local variable... it's a function call that can be avoided.
> >
> > What function call overhead did you have in mind?  `_dos_ds' is a
> > variable, not a function.  (Actually, it's a macro, defined by
> > <go32.h>, because the real name of the variable is too long to
> > type...)
> >
> Sigh, I already admitted that I confused _dos_ds with my_ds();

Incidentally, `_my_ds()' is an inline function and hence does not suffer
the overhead.  A piece of code like:

seg = _my_ds();

will probably compile to:

movw %ds, seg

or some variation thereof.  It's written as a function because DS is
something that can change over the course of the program, and therefore
needs to be "calculated" dynamically.  _dos_ds, on the other hand, is
unchanging.

-- 

Nate Eldredge
nate AT cartsys DOT com