Message-Id: <199709240607.QAA12770@rabble.uow.edu.au>
Subject: Re: (pas d'objet)
To: firewind AT metroid DOT dyn DOT ml DOT org (firewind)
Date: Wed, 24 Sep 1997 16:07:29 +1000 (EST)
Cc: djgpp AT delorie DOT com (DJGPP)
In-Reply-To: <609oql$8ag@dfw-ixnews10.ix.netcom.com> from firewind at "Sep 24, 97 01:02:13 am"
From: Brett Porter <bporter AT rabble DOT uow DOT edu DOT au>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

> Far pointers, now. I'm not sure how these work, exactly; the FAQ doesn't go
> into great detail here like it does for Fat DS. But, the inline declarations
> in <sys/farptr.h> might give some insight; for example, here is the 
> definition for _farpokeb:
> 
> extern __inline__ void
> _farpokeb(unsigned short selector,
>          unsigned long offset,
>          unsigned char value)
> {
>   __asm__ __volatile__ ("movw %w0,%%fs\n"
>       " .byte 0x64 \n"
>       " movb %b1,(%k2)"
>       :
>       : "rm" (selector), "qi" (value), "r" (offset));
> }
> 
> Personally, that's total Greek to me. :)  Can any guru in this area give
> some insight into how\why the far pointer functions work? 

Well, I'm not a guru but I'll give it a shot :) This is allowed to work
because you use a valid selector (allocated by your program or the djgpp
internals) to access memory. Effectivly this inline assembly sets fs to the
selector and stores the byte at the given offset.

> (BTW: Eli: is that a short I see in the prototype? ;)  

Oops... I think I had a fair bit to play in that argument ;) On the serious
side, you need the unsigned short because %fs can only hold a word. I don't
know if int in the prototype would work, but since it is inlined, I guess it
shouldn't.

> The far pointer functions are
> probably named for the fact that the address is not 'visible' per se to
> your application; you have to reach out and grab it, so to speak. In this
> case, the meaning of 'far' in relation to its traditional DOS usage is
> probably much closer; however it can still lead to confusion (as the
> poster demonstrates) when people confuse DJGPP's memory protection for a
> total lack of such things.
> 
It probably only got far because it is the opposite of what has been
proclaimed near in DJGPP :) I mostly agree iwth your comments though,
because this is mostly used for things such as Video memory, which aren't in
your applications address space.

> 
> In short, Fat DS and 'far pointers' shouldn't be used (and can't in Windows
> programming) but are in DJGPP as a way to access low-level stuff quickly.
>

Why shouldn't they be used? Plenty of applications need a way to get at the
video directly or the keyboard, etc.
 
> [- 	    "You're just jealous because the voices talk to -me-."          -]
> 
I hear them too, mostly at 2:00am when I am still coding on my game, rather
than doing my uni. work ;)

-- 
"Give me ambiguity or give me something else"
--
Brett Porter
bporter AT rabble DOT uow DOT edu DOT au

http://www.geocities.com/CollegePark/Union/3596
	Humour, Programming, and more.