Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!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: <14419@bfmny0.UUCP>
Date: 27 Jun 89 17:58:55 GMT
References: <598@philtis.UUCP> <14381@bfmny0.UUCP> <1765@auspex.auspex.com> <190@uvacs.cs.Virginia.EDU>
Reply-To: tneff@bfmny0.UUCP (Tom Neff)
Organization: ^
Lines: 27

In article <190@uvacs.cs.Virginia.EDU> mac@uvacs.cs.Virginia.EDU (Alex Colvin) writes:
>PLM does a nice job in the code generation department...

>iC86, by contrast, has a naive code generator.  This isn't normally a
>problem, unless you're really tight on microseconds.  Since it's not an
>ANSI C compiler, it doesn't give you a lot of control over parameter
>passing (you keep generating code to widen char to int), signed-ness, etc.
>The libraries are pretty antiquated.

Once again, since a lot of people seem to be unaware of this: The iC86
Alex is talking about is the bad, old Mark Williams-derived unusable
atrocity.  (Versions 3.1 and earlier.)  The shiny, new iC86 4.0, out for
well over a year now, is no relation!

Intel wrote a dpANS compatible front end and hitched it to the good PL/M
code generator Alex alludes to above.  The libraries are fine, and available
in all memory models.  You even have builtins available (optionally) for
hardware specific things like OUT and MOVB, so you can use iC86 to write
high performance embedded stuff.  The code is ROMable and interfaces well
with the other Intel languages - PL/M, ASMx86 of course, Pascal, Fortran.

Remember, old C bad, new C good.
-- 
You may not redistribute this article for profit without written permission.
--
Tom Neff				UUCP:     ...!uunet!bfmny0!tneff
    "Truisms aren't everything."	Internet: tneff@bfmny0.UU.NET