Path: utzoo!attcan!uunet!lll-winken!ames!vsi1!daver!lynx!m5
From: m5@lynx.uucp (Mike McNally)
Newsgroups: comp.sys.intel
Subject: Re: PLM vs. C for 80286/80386
Keywords: PLM C
Message-ID: <5711@lynx.UUCP>
Date: 8 Jun 89 15:49:05 GMT
References: <598@philtis.UUCP> <126@tridom.uucp>
Reply-To: m5@lynx.UUCP (Mike McNally)
Organization: Lynx Real-Time Systems Inc, Campbell CA
Lines: 34

In article <126@tridom.uucp> wht@tridom.uucp (Warren Tucker) writes:
>Having programmed PL/M-86 and -186 for three years ...

You see a lot of people like this lined up at Lourdes...

>6.  I haven't seen any C compiler produce such good code for
>the Intel CPU.  

I think that this speaks ill of the Intel C compiler, rather than
well of PL/M.  Last time I looked at PL/M-86 (admittedly a long long
time ago), the code it generated was OK but not spectacular.  I
feel also that a programmer is much more constrained in terms of
source-level optimizations (particularly in the area of manipulation
of data structures involving pointers).

The claim made that PL/M switch statements are always branch table
based is true, but of course that's easy when the case labels are
*always* 0 through N.  And of course, if the selector is out of range,
the results are undefined (no such thing as default:).  Structures
within structures?  Sorry.  Two dimensional arrays?  Sorry.  Macros
with arguments? Sorry.

My guess is that GCC, well-tuned, would beat the pants off of PL/M.
Of course, GCC doesn't generate object files compatible with LINK86.

I don't want this to sound like an attack on PL/M; it's been used a
lot and it's not all bad.  The original request was for opinions,
after all.

-- 
Mike McNally                                    Lynx Real-Time Systems
uucp: {voder,athsys}!lynx!m5                    phone: 408 370 2233

            Where equal mind and contest equal, go.