Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucsdhub!hp-sdd!hplabs!sdcrdcf!ucla-cs!minnie!kennel
From: kennel@minnie.cognet.ucla.edu (Matthew Kennel)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Knowing Machine Code
Message-ID: <13542@shemp.CS.UCLA.EDU>
Date: 14 Jun 88 23:44:45 GMT
References: <13735@comp.vuw.ac.nz> <104700032@uiucdcsp> <4760@husc6.harvard.edu>
Sender: news@CS.UCLA.EDU
Reply-To: kennel@minnie.UUCP (Matthew Kennel)
Organization: none
Lines: 96

In article <4760@husc6.harvard.edu> singer@endor.UUCP (Rich Siegel) writes:
>
>	Call me stupid, but I fail to see why you need two compilers. Why
>not just have an extremely fast compiler that generates better code
>than the competing compilers *AND* is FASTER than it's previous version?
>Then you can have your cake and eat it too: production-quality code
>and near-instant turnaround.
>
>Rich Siegel
>THINK Technologies Division, Symantec Corp.

Yes, that would be nice, but in the best of all possible worlds
we'd all have compilers that would remove bugs from our own
programs etc. (a joke)  Unfortunately it's not, shall we say,
a 'trivial' problem.

I can see a BIG problem with having two different compilers:
they'd compile two slightly different versions of the language.
A program that worked on one would not work on the other.  Of course
if all implmentations were strictly ANSI conforming and we never
ever wrote slightly nonconforming code (we'd never do that would we)
everything might be OK, but I wouldn't trust it.  I think that
a single compiler with various options in the code generator
would be the most trustworthy solution.  

Someone mentioned that "it was a fact" that VMS compilers emit the
best code: I agree that the VMS compilers that I've seen (Fortran
and C) seem to produce very very good code, but they are certainly
NOT especially fast in compiling.  Interestingly, using the
/NOOPTIMIZE switch on the fortran compiler did not make the compiler
much faster: it gained maybe 10-15% but not much more.

(These compilers with /NOOPTIMIZE probably produced better code than
many other compilers I've seen already)

Another problem with hard-core optimization is that it can make
debugging much harder.  If a compiler moves common sub expressions
out of loops, for example, and if the instructions in question
generate some kind of error, the unoptimized and optimized code
might behave quite differently.  The relationship between original
source code and the object code gets more complicated and might
make source-level debugging more difficult.  (In fact, DEC recommends
using /NOOPTIMIZE when using their debugger)  So, there should always
be a way to turn off optimizations---at least those that would make
debugging difficult.  (By optimization I don't mean non-braindamaged
register allocation: that the compiler should do ``in its sleep'')

I hope that Mr. Siegel isn't implying that his company's current
product (LSC 2.15) provides "production-quality code and
near-instant turnaround".  I'll grant him the second, but their code
is far from "production quality".  Maybe people write real commercial
programs with it, but that's because there's nothing better.

I dunno; maybe all of the 68000 compiler gurus work for SUN.  (Look at their
compiler, hint hint)

I don't mean to rag on LSC (I own a copy myself!) but I like everything about
their compiler except the compiler.

======
I have a completely unrelating question that's been bothering me for a long
long time.

When one compiles a floating point program on a non 68881 macintosh one
gets traps to the SANE package, right?  And when one compiles for a 
Mac II one gets real '881 instructions, right?  (in an accusatory voice---
"you do, don't you?")  And if one runs that '881 code on a non FPP
machine you'd get some trap, something like 'unimplemented instruction'
or something like that, right?

Then why doesn't the trap handler call the SANE package for '881 instructions?
ISN'T THAT WHY MOTOROLA PUT THOSE TRAPS IN THERE IN THE FIRST PLACE????!!????

If this had been done 'in the beginning', all compilers could issue nice '881
instructions which would be emulated on Mac I's and would then scream on Mac
II's without ANY change in software! 

Apple, can you hear?
Even now, it's not too late to do it!---it could be easily included in a new System.
And even if Apple doesn't want to admit their mistake I'm sure some other hackers
could.  (LSC 3.1?)  The patch could even be a little INIT (I'm guessing); then the
compiler could always produce '881 instructions.
======

How much optimization does LSC 3.0 do?  I'm guessing that from the lack
of advertizing hoopla (compare the Microsoft C 5.1 ads in PC rags)
the answer is ``not much.''  Especially considering all the emphasis
on the 'source-level debugger.'  Yes, the debugger would be nice, but
also imagine if every program were 35% smaller or faster.... 

(fade to dreamy setting)
"Sure, Fullwrite will work in 1M!"
"Debugger?  No, you don't need any more memory!"
(wake up in cold sweat)


Matt Kennel