🚀 go-pugleaf

In article <126@tridom.uucp> wht@tridom.uucp (Warren Tucker) writes:
>2.  The tools for C language development abound.  The same
>for PL-M are fewer and harder to find.  The same holds for
>the availability of subroutine libraries and programs to
>extract code and ideas from.

Tool availability unfortunately depends on your choice of platform. If 
you have the (mis)fortune to be developing on an iRMX box, you don't 
have a lot of the goodies UNIX or even MS-DOS based folks do. Some you 
can port yourself, but it's not always trivial to take 200k of BSDish 
code and shoehorn it into ANSI C on an alien box with only sketchy 
equivalents for some of the standard UNIX facilities. 

>3.  C is a lot less wordy.  Having refused to use a macro
>for the PL/M DECLARE keyword, my fingers are a great deal
>more tired after finishing a module in PL/M.  EVERY function
>or procedure used in a module not resident in it must be
>DECLAREd EXTERNALly.  This is probably a weaker argument,
>but it counts.

I would like to play devil's advocate here and say that in my 
experience, the need to spell more things out HELPS program 
reliability and maintainability rather than hinders it. Writing your 
first big PL/M source module from scratch can be a bit daunting. 
Writing the next one can usually be accomplished by boilerplating the 
structure of the first one wholesale in the editor and replacing the 
guts with new stuff. That's what I do. On the other hand I have seen 
my share of write-only C and would not care to have to maintain it for 
a living. 

>4.  Support.  I may be wrong, but I think there is a great
>deal more C programmers out there than PL/M.

The problem with PL/M programmers is that they don't know each other
exist!  That's one of the things comp.realtime can help with, also
comp.sys.intel although everyone seems to use that group to beg for
stepping errata sheets. :-)

>5.  PL/M is inherently a strongly typed language.  It is
>very hard to screw up the number and type of parameters
>supplied to a function, etc.  

However see another poster's point that once you pass by ADDRESS,
PL/M gives up the ghost, and this can hurt when interfacing with,
say, FORTRAN.  What that poster didn't point out, though, is that
C is no better at interfacing with FORTRAN!  Things like LINT only
help for C-to-C interfaces.  LINK86 is happy to tell you about
"type mismatches" of course - and will do so at *book length* if
you link C and FORTRAN together with the TYPDEF records still in,
even if you did it *right*.

>6.  I haven't seen any C compiler produce such good code for
>the Intel CPU.  PL/M built-in functions use REP, LOOPxx,
>MOVSB, etc.  in inline code, while C is always calling
>external routines for such things (like _blmv for structure
>assignment).  

No - as of iCx86 3.0 and later (the ANSI versions, post-Mark Williams
atrocity) there is something called <inline.h> which tells the compiler
to generate inline code for MOVB type things.  There is a #pragma inline
(a total kludge) that gets tacked onto the special functions.  If
you leave out inline.h, it resolves them to the RTL I believe.
-- 
You may redistribute this article only to those who may freely do likewise.
--
Tom Neff				UUCP:     ...!uunet!bfmny0!tneff
    "Truisms aren't everything."	Internet: tneff@bfmny0.UU.NET