🚀 go-pugleaf

In article <5711@lynx.UUCP>, m5@lynx.uucp (Mike McNally) writes:
> 
> ...  Last time I looked at PL/M-86 (admittedly a long long
> time ago), the code it generated was OK but not spectacular. ...

I first saw PL/M-86 as part of MDS-311, in 1978.  By 1981, it was ok and
reasonably bug free.  The current PL/M-386, version 1.3, generates what
looks like the same stuff, modified for the 386.  Today, it is not
comparable to the output of a good C compiler (not pcc).  I try to limit
looks at the result of '$CODE', because it always makes me want to chuck it
and write in ASMx86, regardless of whether it is worthwhile.  Current C
compilers rarely do that to me.

If I had to use BND386 and BLD386, perhaps to use ICE386, I would stick
with PL/M.  From the manuals, C386 is a new idea at INTEL.  There are lots
of caveats about C calling sequences, externals vs. common, and so on.
Some day, one can expect C386 to be preferred to PL/M.  However, unless you
work for INTEL, other frontiers look more profitable to pioneer.  Recalling
my stack of PTR's on early PL/M-86, I took my own advice, and so do not
have first hand experience with C386.

No one has mentioned INTEL's new policy on their binary format.  They treat
their relocatable binary format as a top trade secret.  In the old 8086
days, it was proprietary, but with enough non-disclosures, they they would
tell you about it.  This year, I've been told by F.E.'s that even the
absolute format is secret, though some of it is documented in the 1.3
manuals.  The official policy handed out from the Oregon hotline seems to
be that one does not need any PROM programmer, system debugger, or
operating system that is not suppied by INTEL.  If you do not like that,
there is the new HEX386.  I guess RMX386 is finally good enough for all
possible purposes, and we should look for it to replace AIX as the be
all and end all.


Vernon Schryver
vjs@calcite.uucp