Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code

Good grief; comp.compilers suddenly doubles in bandwidth. I won't bother
to quote all of Paul Robinson's posts, but will reply to them all
together.


1. You seem to have a preoccupation with x86 architectures. Please do not
assume that this is shared by most readers of comp.compilers. In
particular, writing "we are inventing the wheel all over again ..." is
assuming such a "we." The readers of comp.compilers include people who
originally invented this wheel.


2. Compilers that precompile or tokenise code during an editing phase are
_not_ "cheating;" they are merely making best use of machine resources
when the processor load is particularly low - you have to wait a million
or more machine cycles for that next keystroke in an editing session.
They are unusual outside of the PC market because almost everyone uses an
unbundled editor (emacs, gnu-emacs, vi, etc) and because people want to
share code with others who don't use the same environment. They are
sometimes found in integrated compiler/environment packages, but these are
expensive.


3. Almost everyone who sells (or gives away) compilers _does_ have a
"double vision" version; it's called optimization. Switch it off and your
code compiles faster but runs slower.


4. Use of a language with a good type system eliminates the
edit-compile-bomb-edit cycle, replacing it with an
edit-typecheck-edit-typecheck cycle. Typechecking is (in general) much
faster than compilation because it includes no optimisation or code
transformations. An SML program which successfully typechecks will not
bomb at runtime.


5. The problem with developing a uniform convention for argument passing
is that the requirements of different languages are fundamentally
different. For instance, it is a natural optimization in SML to keep
function code addressses in closures and to pass the closure of a function
to it in a register, as a hidden argument. This is a completely alien
concept to FORTRAN ("closure? What's a closure?"). There are many other
examples of different requirements. There are mixed-language systems,
such as Poplog, which provides POP-11, Prolog, Common Lisp, SML (and
another language). I have no idea how they manage (say) the SML/Prolog
calling convention; I see no trivial solution.


6. You suggest that because compiler writers often work for compiler
companies rather than hardware companies, they either (a) don't know how
to tweak the hardware in the best way or (b) can't be bothered. (a) is
almost never true these days: hardware specs are very good and working on
a compiler for an architecture is one of the best ways to learn that
architecture inside out (working on an OS is even better). (b) is
occasionally true, but is surely a consequence of insufficient resources:
it seems users are happy to settle for compilers that don't tweak the
hardware as much as they might; if users demanded the best possible
performance they would have to pay more but would presumably get it (this
does in fact happen, and is why some compilers cost a _lot_ more than
others).


Nick Haines nickh@cmu.edu
--

Return to the comp.compilers page.
Search the comp.compilers archives again.