Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!compilers-sender From: rfg@mcc.com (Ron Guilmette) Newsgroups: comp.compilers Subject: Re: Encripted source as an ANDF Message-ID: <3990@ima.ima.isc.com> Date: 27 May 89 20:56:59 GMT Sender: compilers-sender@ima.ima.isc.com Reply-To: rfg@mcc.com (Ron Guilmette) Lines: 109 Approved: compilers@ima.UUCP Posted-Date: Sat, 27 May 89 15:56:59 CDT Recently, albaugh@dms.UUCP (Mike Albaugh) writes: > >From article <3949@ima.ima.isc.com>, by rf@mcc.comg (Ron Guilmette): > [ much serious discussion of the _politics_ of uglified source ] > > > > Another very effective uglifing transformation is to perform comprehensive > > de-structuring, i.e. the conversion of all loops and well structured if and > > switch/case statements into the most degenerative possible equivalent forms > > using GOTO statements... > > ... This transformation is also > > a particularly good candidate for use in an ANDF generator because the > > semantics of the original source code may be strictly manitained, and > > the transformation itself should have little or no effect on the quality > > of the *final* generated (machine-dependent) code (assuming that even > > modest optimizations take place in the ANDF compiler(s)). > > I beg to differ. The sort of transformation suggested here is likely > to cripple the optimization effort, for much the same reason as cited against > RTL and the like. If the code is going to be "optimized" by the original > source->andf translation, assumptions have to be made about the eventual > target. These assumptions are no better than the RTL ones. If the code is > supposed to be optimized by the andf->machine_code translation, then the > control structures and variable scoping need to be preserved so, for example, > register allocation can be done "intelligently". Mike talks about two type of "optimizers" here, i.e. SOURCE => ANDF and ANDF => MACHINE_CODE. One of these possibilities is totally silly, in the current context. The real beauty of the simple idea I proposed was that almost everybody already has a C compiler. In the scheme I suggested, this compiler would also serve (without major modifications) and the ANDF compiler. Given this assumption, it should be obvious that there would be no need whatsoever for a SOURCE => ANDF "optimizer" since the ANDF => MACHINE_CODE transformation (i.e. "normal" compliation") would (presumably) already have a good optimizer. Mike says that even for an ANDF => MACHINE_CODE optimizier, "control structures and variable scoping need to be preserved so, for example, register allocation can be done 'intelligently'". Well, he may have gotten it half right. Scoping information may be useful in this regard, but I never suggested that any scoping information be destroyed. Consider the destructuring of: if () { ... } into: if () goto around_999; { ... } around_999: This destructuring transformation obviously *does not* have any effect on scoping information. Regarding the other half of Mike's argument (i.e. that "control structures" must be preserved to do good optimization) I believe that this is also patently false. I personally know of no reason why this should be the case, and I challenge Mike to produce some evidence or proof that such information improves the ability of an optimizer to do its work (either with respect to register allocation, or with respect to any other type of commonly used optimization mechanism). In fact, quite to the contrary, I believe that the vast majority of modern optimizers begin their analysis by reducing "higher-level" control constructs down to their simpler "GOTO" equivalents. Thus, if this transformation is done at the source level, it should have absolutely no effect on the quality of optimization for most well-written modern optimizers. Mike seems to be saying that there are some optimizers which perform specialized optimizations *only* on control-flow graphs derived from "higher-level" control constructs (e.g. if-then-else, while-do, repeat-while, for, etc.) and *not* on identical control flow graphs which happen to be derived from some GOTO-filled programs. I believe that this is wrong, and that all "good" optimizers look for *all* optimization opportunities wherever they might be found. > For example, we have a locally developed "silliness reducer" which > we use on the output of the GreenHills compiler... > ... [ description of their post-processor which fixes up lousy GreenHills > output code ] ... What does this have to do with anything (other than to demonstrate that GreenHills compilers need more work)? > ... Similar problems would crop up in an uglification that re-used > variables, expecting a specific number to occupy registers. I never suggested this as a "proper" uglification-step for an ANDF generator (and I probably never will)! We *were* talking about de-structuring. // Ron Guilmette - MCC - Experimental Systems Kit Project // 3500 West Balcones Center Drive, Austin, TX 78759 - (512)338-3740 // ARPA: rfg@mcc.com // UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg -- Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU Plausible paths are { decvax | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request