Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!sdsu!lll-winken!uunet!bfmny0!tneff From: tneff@bfmny0.UUCP (Tom Neff) Newsgroups: comp.sys.intel Subject: Re: PLM vs. C for 80286/80386 Keywords: PLM C Message-ID: <14442@bfmny0.UUCP> Date: 7 Jul 89 02:00:33 GMT References: <598@philtis.UUCP> <14381@bfmny0.UUCP> <1765@auspex.auspex.com> <2760@maccs.McMaster.CA> <95@uci.UUCP> Reply-To: tneff@bfmny0.UUCP (Tom Neff) Organization: ^ Lines: 56 In article <95@uci.UUCP> clay@uci.UUCP (News Administrator) writes: >I have actually used the latest (as of Fall, '88) version of Intel C with >a specific eye towards reasonable code and PL/M compatibility. I was pleased >to see both. This is version 3.x (maybe 4.x, I can't remember). This was NOT >the original hack job that was too awful for words. Definitely 4.0 or 4.1. Anything from Intel marked 3.1 or earlier is the Mark Williams C hack job, which was an atrocity. (Parenthetically (he says, in parentheses (hehe)), I want readers of this newsgroup to know that although I know a lot about Intel products and will defend them against ignorant slanders, I also give Intel unmerciful heat about their shortcomings. Ask any Intel FAE who's had to deal with "Neff" at one time or another. [:-)] ) >With regards to PL/M compatibility, there is no way to say "SELECTOR" in C such >that LINK86 will not complain of type mismatches with PL/M modules, but the >code works fine. This is a case where you have to either compile with NOTYPE or eat the type mismatch with a smile. I might add that LINK86 v2.7 hemorrhages TMM's compared to 2.5. If you have ever delved into the Byzantine workings of OMF-86 and tried to figure out TYPDEF records you will see that there about 850 ways to interpret any pair of candidate PUBDEF/EXTDEF symbols in terms of how they express their applicable types. 2.7 seems stricter, and in the cross language world that's a disaster. I make it a habit to strip TYPDEF's before linking cross language jobs. It just ain't worth it - the few legitimate mismatches you might catch are inundated in the bogus ones. >Generated code looks very much like that of PL/M, the default parameter-passing >mechanism is "fixed param" which is like MSC "pascal". I have my qualms about this decision on Intel's part. They support two parameter passing conventions in iC-x86: "varparams," corresponding to the traditional C implementation on 86 architectures, wherein the caller pushes all arguments onto the stack in reverse order, then a count, then calls the subprogram, then cleans up the stack itself; and "fixparams," corresponding to the way PL/M-86, FORTRAN-86 and Pascal-86 work, wherein the caller pushes all arguments on the stack in forward order, then calls the subprogram which is expected to agree on the number and type of arguments and perform its own stack cleanup on return with the RET 86 opcode. The latter method is faster for the majority of cases where in fact the caller and callee expect a fixed list of parameters. The former method is slower to deal with but permits variable parameter lists a la "printf". Intel iC-x86 allows functions to be declared/defined with one or another parameter passing convention via a #pragma (functions of either convention may be mixed within a program); so far so good. What I don't like is that Intel has lately selected "fixedparams" as the DEFAULT convention unless you specifically override. That makes me a bit queasy. I doubt Doug Gwyn reads this newsgroup but if he does I bet it would make him a bit queasy too. -- "My God, Thiokol, when do you \\ Tom Neff want me to launch -- next April?" \\ uunet!bfmny0!tneff