🚀 go-pugleaf

I had limited experience with PLM on iRMX86.  I've used iNtel's old iC86 on
iRMX and Turbo C on DOS.

PLM does a nice job in the code generation department.  A construct such as:
	call Fred(); do while (UnDone); call Fred(); end;
has the branches rearranged into
	RepeatL: call Fred(); if (UnDone) goto RepeatL;
thereby overcoming some if the inexpressiveness of PLM.

iC86, by contrast, has a naive code generator.  This isn't normally a
problem, unless you're really tight on microseconds.  Since it's not an
ANSI C compiler, it doesn't give you a lot of control over parameter
passing (you keep generating code to widen char to int), signed-ness, etc.
The libraries are pretty antiquated.

I was trying to maintain compatible sources for a network controller across
the two systems.  The differrence between PC-bus and Multibus was handled
by linking in different libraries.  The big problems were incompatibilities
in C language & (non-)standard libraries.

PLM isn't compatible with anything else, so this won't bother you.  It's
related to PL/I only in syntax.  Their implementation of BASED storage ties
data structures to a particular pointer, making it hard to write reentrant
code.  You wind up having to re-declare your structures all over the place,
making the code hard to maintain.  Macros are a clumsy way to get around
this.  At least C permits you to re-use a STRUCT declaration.

PLM does give you access to selectors (tokens) and other peculiarities of
the architecture and OS, where C will require lots of casting.  PLM has
argument type checking, where iC86 doesn't.  PL/M pointers are totally
untyped, where iC86 will cast.

If the rumor of an ANSI-type C compiler is true, I'd recommend that.  The
(optional) stronger typing is likely to save you a lot of headaches.  You
stand a greater chance of stealing code from other applications.