Xref: utzoo comp.sys.intel:518 comp.lang.misc:1810
Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!netnews.upenn.edu!eniac.seas.upenn.edu!blackman
From: blackman@eniac.seas.upenn.edu (David Blackman)
Newsgroups: comp.sys.intel,comp.lang.misc
Subject: Re: PL/M
Keywords: software development PL/M SELECTOR
Message-ID: <4984@netnews.upenn.edu>
Date: 2 Sep 88 22:25:47 GMT
References: <17377@gatech.edu> <1627@edison.GE.COM>
Sender: news@netnews.upenn.edu
Reply-To: blackman@eniac.seas.upenn.edu (David Blackman)
Organization: University of Pennsylvania
Lines: 29

I would like to point out one feature in PL/M-86 which makes it better
suited for iAPX processors than most other languages - that is the
SELECTOR data type.  A SELECTOR is just a (16 bit) data type which
is used like a pointer.  Of course, a 16 bit pointer is not sufficient
to address the full 8086 address space.  To use SELECTORs, you use the
convention that all SELECTOR-referenced objects are allocated on paragraph
boundaries.  Such a convention is used in iRMX-86.  Under such an
allocation convention, the SELECTOR will be the segment of the object's
address; the offset of the object's address will be 0.  

SELECTORs don't help you out much with objects in the data or stack segments.
You usually use them to reference objects which are dynamically allocated out
of a heap.  The advantages of SELECTORs include:

1. you can pass addresses around using a 16 bit SELECTOR rather than a 
   full 32 bit POINTER.  Structures containing pointers (linked lists,
   trees, etc.) shrink.

2. forming effective addresses for array elements or record fields is
   simplified.  You just use the SELECTOR as the segment.  The array index
   or record field displacement is used directly as the offset.

3. The scheme would be compatible with the 286 protection scheme.  You
   gain per-segment protection on each reference to data.

4. Pointers can be ambiguous - are the addresses 0:100 and 10:0 "equal"?
   SELECTORs are unique.

David