Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!bellcore!texbell!sugar!ficc!karl
From: karl@ficc.uu.net (karl lehenbauer)
Newsgroups: comp.realtime
Subject: Re: Searching for realtime languages
Message-ID: <4423@ficc.uu.net>
Date: 6 Jun 89 14:05:11 GMT
References: <699@tuvie> <2100@internal.Apple.COM> <14355@bfmny0.UUCP> <14360@bfmny0.UUCP>
Distribution: all
Organization: Ferranti International Controls
Lines: 23

If I may throw my $0.02 into the merits of PL/M, the 80286 PL/M generates 
excellent code under optimize 3, although it does occasionally misoptimize 
and produce bogus code (at level 3) :-(

PL/M, as has been noted, locks one into Intel architectures, and it took Intel
a rather long time to make the compiler available for the 386 as well.

Tom Neff pointed out that as of PL/M 2.7 many limitations on structure nesting,
number of elements, etc, have been removed or substantially reduced.  This is
a good thing, but the restrictions were a pain and there is a lot of existing 
code that was written, and kludged, because of the previous limitations.

I think the most apalling thing about the language itself, and the part that
has caused me the most personal grief, is that pointers don't have data types.
Thus, a lot of improper use of pointers which would cause warnings (at
least) from most C compilers are passed without comment by PL/M and one gets
to find the problem by debugging.  We do a lot of stuff that has to be
FORTRAN-callable, and *all* the parameters for a PL/M routine that's FORTRAN-
callable have to be pointers, so a lot of the benefits of data type checking
by the compiler are lost to us.
-- 
-- uunet!ficc!karl	"Contemptuous lights flashed across the computer's
-- karl@ficc.uu.net	 console."  -- Hitchhiker's Guide