Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!purdue!decwrl!decvax!ima!compilers-sender
From: albaugh@dms.UUCP (Mike Albaugh)
Newsgroups: comp.compilers
Subject: Re: Encripted source as an ANDF
Message-ID: <774@dms.UUCP>
Date: 23 May 89 19:01:17 GMT
References: <3949@ima.ima.isc.com>
Sender: compilers-sender@ima.ima.isc.com
Reply-To: albaugh@dms.UUCP (Mike Albaugh)
Organization: Atari Games Inc., Milpitas, CA
Lines: 45
Approved: compilers@ima.UUCP

>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 alone should reasonably
> prevent any theft of ideas (or code) given that it is guaranteed to make
> the resulting code totally incomprehensible.  Given the current state of
> the art in the area of restructuting tools, this is also (effectively) a
> one way transformation for many languages.  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".

	For example, we have a locally developed "silliness reducer" which
we use on the output of the GreenHills compiler. We hesitate to call it
an "optimizer, because the resulting code is far from optimal, but it does
a fair job of deleting dead code, extraneous reg-reg moves, etc. One
headache was that the compiler uses D0 as the return register as well as
its most_favored_temp. If one only has the assembly code to inspect, it
is impossible to tell whether a seemingly dead calculation is really a
return value. Similar problems would crop up in an uglification that re-used
variables, expecting a specific number to occupy registers.

| Mike Albaugh (albaugh@dms.UUCP || {...decwrl!turtlevax!}weitek!dms!albaugh)
| Atari Games Corp (Arcade Games, no relation to the makers of the ST)
| 675 Sycamore Dr. Milpitas, CA 95035		voice: (408)434-1709
| The opinions expressed are my own (Boy, are they ever)
--
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