🚀 go-pugleaf

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
<NN> 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