www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1995/06/01/02:45:58

Date: Thu, 01 Jun 1995 17:07:43 +1100
From: Bill Currie <BILLC AT teleng1 DOT tait DOT co DOT nz>
Subject: Re: dpmi DS:VRAM hack
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Organization: Tait Electronics Ltd.

> Date:          Wed, 31 May 1995 22:34:39 -0400
> From:          dj AT delorie DOT com (DJ Delorie)
> To:            Giva AT bbb DOT no
> Cc:            djgpp AT sun DOT soe DOT clarkson DOT edu, Giva AT bbb DOT no
> Subject:       Re: dpmi DS:VRAM hack

> 
> > Another solution to all these far-memory tricks (and hacks) would be
> > real far-pointers. How difficult would it be to implement this in
> > GCC ? This is a FSF issue I presume, but the djgpp community has lot
> > of pull there.
> 
> Not really.  The FSF isn't driven by the market, they are driven by
> what they want to do.  No number of people can influence those who
> aren't concerned with the number of people involved.
> 
> Implementing far pointers in gcc, I've been told, is very difficult
> because the compiler just can't handle the case where one pointer is
> expressed by a combination of two registers.  Especially when you can
> combine these registers in arbitrary ways.

If it hasn't already been suggested, what about a secialized class
for C++ or macro set for C.  For the macros, uou could a macro that
loads a specified segment register with the desired selector and
then in your loop use another macro that takes as its arguments the
segment register to use and the offset.  This does cause its own
problems (such as restoring the previous value to the sr when done)
but it would certainly be workable.

Bill

- Raw text -


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