Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!snorkelwacker!mit-eddie!bu.edu!bu-cs!mirror!prism!rob
From: rob@prism.TMC.COM
Newsgroups: comp.sys.ibm.pc
Subject: Re: SEGMENT:OFFSET Madness
Message-ID: <206900160@prism>
Date: 15 Jan 90 18:22:00 GMT
References: <25821@cup.portal.com>
Lines: 28
Nf-ID: #R:cup.portal.com:-2582100:prism:206900160:000:1469
Nf-From: prism.TMC.COM!rob    Jan 15 13:22:00 1990


pipkins@qmsseq.UUCP writes:

>With the advent of protected mode on the '286 and V86 mode on the '386,
>the value in the segment register really is a segment number, but a segment
>is no longer (necessarily) 64k bytes.  It is a segment selector.  This also
>presents real problems (no pun intended).

>On the 8086, before there was an 80286, it was perfectly legitimate to 
>normalize the address so that the segment was between 0 and F.  Programs
>that use this technique will not run under '286 protected mode or V86
>mode on the '386. 

   Perhaps a nit, but in V86 mode on the 386/486, the segment registers
aren't treated as protected-mode style selectors, but as real-mode style
pointers to memory paragraphs (though the physical memory they point to
can be altered via the paging tables). That's the 'magic' of V86 mode;
it lets real mode programs run under protected mode by using real-mode
segment translation. As a result, the normalization you mentioned (which 
is used in accessing 'huge' arrays) is acceptable under V86 mode, though 
not under standard 286/386/486 protected mode.

   Ideally, address normalization should be unnecessary under 386/486 
protected mode anyway, since it allows segments to be arbitrarily large.
A type of normalization can be performed under 286 protected mode if
the operating system sets up descriptor tables the right way (OS/2
does this with the various DosGetHuge...() functions). It's slow and
cumbersome, but it works.