🚀 go-pugleaf

Intel's PL/M-86 (-286, etc) is a very good, meat and potatoes language
for "pure" systems programming on iAPX class processors.  I have used
it extensively in dedicated target systems for six or seven years.
What it lets you do is program right down to the iron (including
interrupt handlers and time critical OS components) in a high level,
procedural language, instead of having to do the "gut work" in
assembler.  As other posters have pointed out, it has no runtime
library at all.  This is entirely intentional, and often essential when
you are doing my type of application.

In terms of the power of the language, I could theoretically use C for
most of what I do, but three factors have militated against it: (a) C
doesn't normally give you the kinds of 86 hardware primitives (inline)
you need to get time critical stuff done; (b) almost every
implementation saddles you with a runtime library which you may or may
not be able to ROM and run reentrant; and (c) Intel's own pathetic
excuse for a C compiler -- adapted from an early version of Mark
Williams C -- is a total abortion nobody could use for real work.
(Nowadays Microsoft C does a good code generation job, but it doesn't
write vanilla OMF object records I can link into my system.  Intel is
planning to ditch MWC completely and replace it with their own C
compiler built around the excellent PL/M code generator, but that will
Take a While.)

Now, if the way you plan to use "iAPX processors" is to sit and write
little programs on an IBM PC, I wouldn't recommend bothering with any
of the Intel language products, including PLMx86.  Instead you need
Turbo C, Prolog etc.  But in the event that your department wants to do
A/D sampling or other such realtime work using Intel processors, I
suspect PL/M would be a good, maintainable choice for the project.
-- 
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)