Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!ucsd!pacbell.com!decwrl!sgi!calcite!vjs
From: vjs@calcite.UUCP (Vernon Schryver)
Newsgroups: comp.sys.intel
Subject: Re: Intel-8086/80186-Assembler for System-V available ?
Message-ID: <97@calcite.UUCP>
Date: 14 Oct 90 20:23:20 GMT
References: <15919@bfmny0.BFM.COM> <1990Oct11.084750.1183@orfeo.radig.de> <15947@bfmny0.BFM.COM>
Organization: Rhyolite Software, Mountain View, CA
Lines: 57

In article <15947@bfmny0.BFM.COM>, tneff@bfmny0.BFM.COM (Tom Neff) writes:
> This, of course, dates from the long-forgotten days when micros were
> required to do useful WORK to earn their supper; unlike our modern
> all-electric era when they're expected to spew waste-cycles doing
> pointless X Windows crap like all the other CPUs.

In my view, the morbid obesity of modern systems is in the tradition of the
half hearted effort put into the PLM86 compiler in 1979.  PLM86 was a crock
in 1978, perhaps justified by pressures to beat the Z8000 and 68K to market.

>           It [PLM386] doesn't do quite so many wild ass optimizations as
> whatever precious academic effort has everyone's heart a-flutter this
> week.  But it is very *predictable* and that is extraordinarily
> comforting in a number of unglamorous, rent-paying types of situations.

That's good only if your rent-paying situations permit 3x the RAM, 1/3
the performance, and 3x the time-to-completion because the tools are so
primitive.  I found the tools primitive compared to previous experience
when first introduced to them in 1978, and see no sign in recent glossy
INTEL releases, cataloges and brochures that much has changed.

Do you really consider the C from GNU, MIPS, SGI, DEC, and Sun "academic"?

> >Anyone with freedom of choice (i.e. no dusty albatrosses) would choose
> >almost any C compiler.
> 
> Oh yeah?  I suggest looking at the original Mark Williams C compiler,
> which was OEM'd as "Intel C" up through 3.0.  ...

I wrote "<almost> any C compiler" on purpose.  How do GNU gcc and
Greenhills gcc compare to PLM/386?  The little Greenhills *86 code I've
read was a breath of fresh air.  How is the AT&T C compiler?

>                                  ...  If you want to generate OMF ...

What's the attraction of OMF, either the old "open" version or the new
proprietary one?  What's wrong with a.out, coff, or even elf?  If you
must have OMF, you probably need it for some PLM that will not die.

It would have been trivial to convert coff et al to the old OMF with a
little hacking (I did a little of that in about 1979); I bet it would be
easy to reverse engineer a coff-to-new-secret-OMF today.  What's hard about
writing your own a.out or coff downloader?  Or just blowing PROM's from
a.out directly?  (A.out is very simple on purpose, so the UNIX kernel can
handle it.)  Imagine using ancient UNIX tools such as make, grep, find,
awk/sed, sh/csh/perl, sort, dbx/sdb/adb, vi/ed/ex/emacs, lex/yacc directly
when developing for *86's, instead of standing on your head to work around
the wonders of UDI/DOS/VPix.

Of course, if technical considerations were paramount, you would choose any
of the CPUs designed in the last 10 years with benefit of the *86
experience, such as MIPS, 88K, 29K, or SPARC.  I've recently found the 29K
great for embedded control, altho the C compiler is dreadfully similar to
the INTEL notion of "good enough."


Vernon Schryver,    vjs@calcite.uucp