Related articles |
---|
[12 earlier articles] |
Re: Help on disassembler/decompilers dik@cwi.nl (1990-09-10) |
Re: Help on disassembler/decompilers markh@csd4.csd.uwm.edu (Mark William Hopkins) (1990-09-10) |
Re: Help on disassembler/decompilers Jonathan.Bowen@prg.oxford.ac.uk (Jonathan Bowen) (1990-09-13) |
Re: Help on disassembler/decompilers nreadwin@miclon.uucp (1990-09-13) |
Re: Help on disassembler/decompilers td@alice.UUCP (1990-09-13) |
Re: Help on disassembler/decompilers kym@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (1990-09-14) |
Re: Help on disassembler/decompilers hankd@dynamo.ecn.purdue.edu (1990-09-14) |
Re: Help on disassembler/decompilers hawley@icot32.icot.or.jp (1990-09-15) |
Re: Help on disassembler/decompilers ch@dce.ie (1990-09-14) |
Re: Help on disassembler/decompilers kym@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (1990-09-15) |
Re: Help on disassembler/decompilers roland@ai.mit.edu (1990-09-16) |
Re: Help on disassembler/decompilers raulmill@usc.edu (1990-09-16) |
Re: Help on disassembler/decompilers ch@dce.ie (1990-09-18) |
[4 later articles] |
Newsgroups: | comp.compilers |
From: | hankd@dynamo.ecn.purdue.edu (Hank Dietz) |
In-Reply-To: | <11326@alice.UUCP> |
Keywords: | Fortran, design |
Organization: | Purdue University Engineering Computer Network |
References: | <HOW.90Sep5173755@sundrops.ucdavis.edu> <6839.26ea3b0e@vax1.tcd.ie> <3972@bingvaxu.cc.binghamton.edu> |
Date: | Fri, 14 Sep 90 16:42:52 -0500 |
In article <11326@alice.UUCP> you write:
>vu0310@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (R. Kym Horsell @ SUNY Binghamton, NY) says:
>>I have made various attempts at writing assemlber -> HLL translators over
>>the years, mostly inspired by the `beatify' tool that attempts to transform
>>spagetti FORTRAN into structured FORTRAN.
>
>Wouldn't a `beatify' tool transform Profane Fortran into Blessed Fortran?
>[We could always hope so. -John]
Nope. The key transformation in fixing spaghetti code is an oldie but
goodie called "code straightening." It's usually pretty easy.
However, such transformations are generally not very good at dealing with
comments. Not only are they notoriously bad at creating meaningful new
comments automatically, but they don't even really know what to do with the
comments that were in the original source.
This last problem is rooted in the fact that most languages do not
syntactically group comments with the source code constructs to which they
apply (they are usually implemented as a lexical hack -- removed from the
source before syntax analysis). Further, how does a beautifier know what
the comment refers to -- it would be pretty strange, for example, to retain
a comment about multiplying things when the multiply has been
strength-reduced out of existence?
One might argue that the big problem in programs today isn't unstructured
use of GOTO, but unstructured use of comments.... One of my PhD students
(Eng-Siong Tan) is currently investigating this problem....
-hankd@ecn.purdue.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.