Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sgi!calcite!vjs From: vjs@calcite.UUCP (Vernon Schryver) Newsgroups: comp.sys.intel Subject: Re: PLM vs. C for 80286/80386 Summary: PL/M is still the same Keywords: PLM C Message-ID: <44@calcite.UUCP> Date: 10 Jun 89 23:15:54 GMT References: <598@philtis.UUCP> <126@tridom.uucp> <5711@lynx.UUCP> Organization: Rhyolite Software, Mountain View, CA Lines: 36 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