Mail Archives: djgpp/1996/05/03/08:20:12
> Although this could be done, if you *absolutely* want it (look up the
> 'nearptr' method in libc.inf and the FAQ list), it will cost you too
> much to be really useful. The reason is that by doing this, you won't
> necessarily drop out of protected mode (which you generally *can't* in
> DJGPP), but you loose almost all the *protection* that way.
I know, that's why I wanted another method ...
> You had better switch coding style and access the screen by specialised
> routines (conio.h routines come to mind) in all your programs, and
> likewise for other 'direct memory manipulation' techniques: if you want
> to peek and poke, then why not use functions like DJGPP's
> farpoke*/farpeek*? (BTW, I think similar functions are available in
> Borland C as well, so this could actually *increase* portability!) These
> functions are inlined, generally, so there won't be any real speed
> penalty compared to direct array manipulation.
Are you sure Peeks and Pokes are as fast as direct memory manipulation??
Peeks and Pokes need to resend to memory segment and offset everytime it
is used. Using multiple array assigments (ie allo[x] = z; allo[x+1] = z;
somehow in the same "structure") it cuts the need to generate new memory
assignments. Good compilers, I think, with optimisation will generate a
memory pointer only once, then use it for all other array assignments
next to it.
> Hans-Bernhard Broeker (Aachen, Germany)
Francois Leblanc (Montreal, Quebec/Canada) :)
- Raw text -