Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!decwrl!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!dorner
From: dorner@uxg.cso.uiuc.edu
Newsgroups: comp.sys.mac.programmer
Subject: Re: Knowing Machine Code
Message-ID: <40600010@uxg.cso.uiuc.edu>
Date: 15 Jun 88 17:41:00 GMT
References: <13735@comp.vuw.ac.nz>
Lines: 18
Nf-ID: #R:comp.vuw.ac.nz:13735:uxg.cso.uiuc.edu:40600010:000:872
Nf-From: uxg.cso.uiuc.edu!dorner    Jun 15 12:41:00 1988


>I'm no expert on compiler technology, but I think some of the most
>powerful optimizing compilers build a parse tree in memory and then
>apply all sorts of heuristic reorganizations to the tree.  Also, some
>                                                             ...  This
>multiple-pass approach makes this type of optimizing compiler
>fundamentally slow.  ...

Not only that, but by the time the optimizer is done messing with your
code, it may have removed, re-ordered, or lipo-suctioned large sections
of your program.  This makes debugging from your source a wee bit
confusing, whether done at source level or assembly level.

>Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
>            {gillies@cs.uiuc.edu}
----
Steve Dorner, U of Illinois Computing Services Office
Internet: dorner@uxc.cso.uiuc.edu  UUCP: seismo!uiucuxc!dorner
IfUMust:  (217) 333-3339