🚀 go-pugleaf

In article <1851@gitpyr.UUCP>, Kevin Kleinfelter writes:
Organization: AT&T Information Systems, Holmdel NJ
Lines: 46
CC: dmt



> In article <494@ubvax.UUCP>, skip@ubvax.UUCP writes:
> > 
> > 	When a program loads a segment register on an 8086, it is
> > 	actually loading a displacement value.  On the 80286, what
> > 	is loaded is actually a segment number indexing to an entry
> > 	in the master segment table.  The actual displacement value
> > 	is loaded from that table.  There is NO relation between
> > 	segment N and segment N+1 (ie N+1:0 != N:10h).
> >
> So how will one compare pointers?  If you can't normalize them, two pointers
> could reference the same address, but not contain the same values.  In
> a language such as Pascal, equality is a valid test on pointers.  In a language
> such as Modula-2, pointer arithmetic is valid.  How can items such as these
> be implemented without normalization of pointers?

A valid concern, but also a concern with the 8086.  Actually, the inequality
above should not say "not equal"; it should say "doesn't necessarily equal".
It is possible to design compilers (or even write your own ASM code -- ugh!)
for the 286 that (1) preserve the 8086 segment-offset relation, or
(2) use protection to allow any address to be accessible from only ONE	
possible segment value.  Note that:

   -	(1) is wasteful of the 286 power.  That doesn't mean it's a silly
	thing to do.  A recent Intel AppNote on the LOADALL instruction
	shows how to emulate REAL MODE in protected mode to run
	pre-existing programs from the 8086.
	
   -	(2) is a very safe way to allow pointer comparison.  It allows you
	to use the SEG:OFS as a REAL 32-bit pointer.  (Well, sort of "real".
	You still have to do your pointer arithmetic being consciously
	aware that it's two 16-bit words.)  I suspect it will
	be a popular choice for native-mode 286 code generators.

Note that (1) and (2) are only a couple of the myriad choices you have
for using segments in the 286.  How the segments are used is less
a function of the hardware than how your compiler chooses to generate
its code.

             		Dave Tutelman
                	Physical - AT&T Information Systems
                  		Room 1H120
                   		Juniper Plaza, Route 9
                  		Freehold, NJ 07728
                	Logical -  ...ihnp4!mtuxo!mtuxt!dmt
             		Audible -  (201) 577 4232
---------------------------------------------------------------