Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1624
| From | federation2005@netzero.com |
|---|---|
| Newsgroups | comp.compilers |
| Subject | I'm rewriting Indent. (Or: automated code synthesis/decompilation) |
| Date | 2015-09-29 17:56 -0700 |
| Organization | Compilers Central |
| Message-ID | <15-09-029@comp.compilers> (permalink) |
Alongside the parser generator project I mentioned a short while back this is another utility I've passed through the first state of rewrite. Again, as in the case of Yacc/Bison, everything up to this state is equivalence-preserving so that the provided regression tests are made to pass. (That includes adding the latest the Linux/Ubuntu fixes to fix problems that are still present in the latest GNU version). Here, the normalization involved in the rewrite brought the source down to about 4000 lines into a form that will greatly facilitate future development and expansion. Actually it was my intent to embody the procedures themselves in a repurposed "indent" and make *it* do all the work (both for this and the other projects I have in my list -- about 100 in all ranging from 10000-750000 lines each). A few words about this utility, particularly its relation to both compilation and the *inverse problem*: decompilation: indent is a code synthesis tool at its root. As it stands are present, it is the only tool I'm aware of that makes use of the THIRD major field of language theory. While compilers are almost exclusively concerned with semantics (the back end) and syntax (the front end), almost never do you see anything that concerns itself with PRAGMATICS! Indeed, the only mention you ever see of this field is in the guise of "whose style is the best" debates, Well, indent is a tool for what we may call Applied Pragmatics. And this is really the root of the matter of another field which we may call Code Synthesis. Although Indent keeps close to the original source it reworking it does (thus identifying it as a literal translator rather than one that paraphrases or takes liberties), if it is retargeted to different output languages and resourced to different input languages and is expanded to do analysis it could just as well serve as a HLL - HLL translator or even a Binary or ASM - HLL translator if a few more elements (that lie at the core of compilation theory and control flow analysis) are included. Thus, I'm aiming to not merely repurpose this as a "automated coding as I do" tool (since the standard "indent" can only automate about 80% of what I do) but a bona fide code synthesis tool. Some of the most important places where you would like to see such an application or routine are Yacc/Bison itself (to take the place of the "skeleton" routines used in the parser generator) and in code like FFTW (where the Fourier-transform related codelets are synthesized for a given host environment). It would also come handy as a device that would allow you to completely gut the huge legacy nightmare that's accrued in sources like GNU's (with its heady make, automake, configure regimen). For instance, instead of adding huge conditional sets of fixes in *every distribution* to cater to the few, you should be providing a single distribution that accords with the latest standards and providing a )re)synthesis tool separately for any who need to adapt to older or non-standard architectures. Also include the kind of things that CFront does (which is *still* in active development) or F2C (fortran to C). The key difference between synthesis and simply re-laying out code and even the extra steps taken to "normalize" (which may include updating the language to more recent standards or take full advantage of recent or current features that few people make full use of) is that with synthesis there is also control flow analysis going on and variable live/dead or in/out analysis ... the same as when designing a good compiler. This is best seen in, for instance, in the kinds of analysis that would be required to turn Fortran into idiomatic C or C++. The F2C converter is okay, but it basically drops the ball on handling Fortran subroutine parameters in a smart way. To this end I will probably be making use of the "Magic Algebra" which I posted a description of here back earlier last decade. In addition I'm also doing a comparative assessment with the code synthesis facilities present in places like FFTW (which are actually carried out in CAML, BTW).
Back to comp.compilers | Previous | Next | Find similar | Unroll thread
I'm rewriting Indent. (Or: automated code synthesis/decompilation) federation2005@netzero.com - 2015-09-29 17:56 -0700
csiph-web