Re: TXL Experience

E.J.Poole@newcastle.ac.uk (E.J. Poole) writes:
> Does anyone have experience of using TXL Version 7? I would be interested
> to see what results people have obtained by using it. I would like to use
> it to read in C++ source code and produce an ASCII file containing a
> description of the program's design to be read into a specific CASE tool.
> i.e. reverse engineer the source code! Anyone got any comments or
> suggestions for an alternative tool or tools? All suggestions or comments
> welcome.


J.P.M.deVreught@CP.TN.TUDelft.NL ("Hans de Vreught") writes:
> Since Txl is using a backtrack parser it ain't suited for your C++
> translator. Don't forget: Txl is a *tree* transformer. The part from
> *language* to *tree* is non-important WRT Txl's objective. In other words:
> the input language should be extremely simple, say strict deterministic,
> for Txl to do its job fast. I find it regrettable that they used such a
> shaky parser (WRT the time complexity), because syntax is quite nice and
> the speed of the transformations are quite accaptable. BTW, the backend of
> Txl is bit simple too (not for suitable for real production).


Since TXL has already been used in a significant design-recovery-
from-source project carried out for IBM Canada, there is no question that
it is well suited to the task you describe. In that project, a
Prolog-style design factbase was automatically inferred from 10,000 lines
of Turing+ source code using a five stage TXL transform from Turing+
source (which is general enough to apply to *any* Turing+ source input and
has subsequently been used on other programs). If you are interested I
can send you the TXL sources for that set of transforms.


As far as parsing speed is concerned, as noted by both Ian Carmachael and
Nick Graham, TXL's generalized top-down parser is very sensitive to the
form of the input. Thus if you feed it a naive LALR Yacc-style grammar,
it will take forever to parse using it. However, if you give it an LL(k)
or transition diagram-style grammar of any kind, it will parse very
quickly. This is no surprise in a top-down method.


The parse phase of the transform I mentioned above above scans and parses
Turing+ source at about 37,000 lines per minute on a Sparc 10. Not
production speed, but not slow. Moreover, as Ian notes, even the naive
C++ 2.0 grammar didstributed with TXL 7.4 parses at about 28,000 lines per
minute on the same machine, and this can be improved with simple tuning
(ask me for a better one, we transform C++ these days).


Part of the power and convenience of TXL lies in the ability to tune the
grammar to the task, and experienced users do that all the time. Tools
with fixed grammars do not provide this extra flexibility, and some tasks
can be very difficult without it.


As far as production-quality is concerned, TXL was designed as a rapid
prototyping tool and in general is best suited to that kind of task.
However, for many tasks it can and does serve as a production system, and
many people use it that way.


'Simplicity' of the back end is a criticism I have never seen before. To
my knowledge, no task has ever been seen to be beyond the (reasonably
convenient) capabilities of TXL transformation rules. After more than
four years of public TXL use, ruleset paradigms have been outlined for
every almost any kind of structural analysis or transformation task.


Interesting that no one on the TXL project has been informed of the
difficulties or limitations noted by Hans. We provide a fairly good
support service to get people past such things, and regularly review the
language and system to respond to new requirements of the user community.


Jim Cordy
TXL Project
--
Prof. James R. Cordy Software Technology Laboratory
cordy@qucis.queensu.ca Dept. Computing & Information Science
+1 (613) 545 6054 / FAX +1 (613) 545 6513 Queen's Univ., Kingston, Canada
--

Return to the comp.compilers page.
Search the comp.compilers archives again.