Xref: utzoo comp.sys.intel:521 comp.lang.misc:1813
Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!hoptoad!dasys1!tneff
From: tneff@dasys1.UUCP (Tom Neff)
Newsgroups: comp.sys.intel,comp.lang.misc
Subject: Re: PL/M
Keywords: software development PL/M SELECTOR
Message-ID: <6265@dasys1.UUCP>
Date: 6 Sep 88 03:52:48 GMT
References: <17377@gatech.edu> <1627@edison.GE.COM> <4984@netnews.upenn.edu>
Reply-To: tneff@dasys1.UUCP (Tom Neff)
Organization: Independent Users Guild
Lines: 19

David Blackman mentioned the SELECTOR data type and how useful it is.
One of the things I like about PL/M is that you can BASE variables on
any of three data types: POINTER, SELECTOR or WORD.  BASED POINTER
assumes full 32-bit indirect reference (except for $SMALL model which
behaves differently in many ways), BASED SELECTOR assumes the variable
lies at offset:0000 in the paragraph pointed to by the SELECTOR base,
and BASED WORD assumes the variable lies in your current data segment,
at the offset pointed to by the WORD variable.  Hours of family fun.

Oh, and last time I forgot to mention the other neat thing PL/M provides:
Extended Segmentation models of compilation.  Lets you divide a system
into subsystems, each of which communicates within itself via 16-bit
references between separately compiled modules, while "exported" references
across subsystems are full 32 bit.  Very sophisticated, you normally need
assembler to do something like that.
-- 
Tom Neff			UUCP: ...!cmcl2!phri!dasys1!tneff
	"None of your toys	CIS: 76556,2536	       MCI: TNEFF
	 will function..."	GEnie: TOMNEFF	       BIX: t.neff (no kidding)