Path: utzoo!attcan!uunet!cs.utexas.edu!usc!snorkelwacker!spdcc!esegue!johnl
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.sys.ibm.pc
Subject: Re: SEGMENT:OFFSET Madness
Message-ID: <1990Jan12.151215.1433@esegue.segue.boston.ma.us>
Date: 12 Jan 90 15:12:15 GMT
References: <25821@cup.portal.com>
Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine)
Organization: Segue Software, Cambridge MA
Lines: 29

In article <25821@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes:
>To get the "real" segment, you must multiply (base 10 
>this example) the so-called segment by 16 and add the 
>offset. Then you must subtract 65,536 from this total 
>repeatedly and stop just before you get a negative 
>number. Then number of times you subtract is the "real" 
>segment number, and your remainder is the "real" offset 
>address.

I suppose that's one way to look at it, but I find it more convenient
to write my programs so that the segments I use are disjoint, keeping
the knowledge of how segments map to linear addresses restricted to
the memory allocator.  Intel in its programming manuals has always
urged people to do that.

If you look at the 286 and 386, you'll find that in protected mode
the segments really are segments, and there is no architectural
relationship between segment N and segment N+1 (well, actually N+8,
but that's a separate argument.)  If your programs are written believing
that segments are segments, they are relatively straightforward to port
to a protected environment.  If you wire in knowledge of the 8086's
16-byte paragraphs, you're in trouble.

I am no fan of 16-bit segments and offsets, but if you have to deal
with them, you might as well make the best of it.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."