[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp

From: Jacob Bachmeyer
Subject: Re: Emacs contributions, C and Lisp
Date: Mon, 12 Jan 2015 17:21:21 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

David Engster wrote:
Jacob Bachmeyer writes:
Dumping an AST that contains only annotations to text, referring to
positions in the source files instead of actually including text in
the AST, looks to me like a good middle ground.  Such an AST (which I
will call a "refAST" because it contains only references to program
source text) would be a significant pain to use as compiler input,

There's no significant pain in looking up the names from the source
files. Also, I see absolutely no point in somehow obfuscating the AST,
since for feeding things like LLVM, there are much simpler options, like
you have noticed yourself (see below).

It's not so much intentional obfuscation, as obfuscation as a side-effect of optimization. Admittedly, a refAST is simple to convert back into a full AST, but doing so is an effort that should give a hint that "you are not supposed to be doing this".

Further, the refAST needs to resemble the source text as closely as
possible.  Most of GCC's value is from the optimizer and code
generators.  Parsing is relatively simple compared to the rest of GCC.

I don't think the guys maintaining the C++ frontend would agree...

Then C++ is even more complex than I had thought. I last used it for a freshman course in college some years ago.

Further reading reveals that for better or for worse, this ship has
already sailed and GCC has had an option to dump GIMPLE
representation, which is probably far more useful for abusing the
frontend than an AST dump, for some time now.

That's what I said from the beginning, and it's my main point why all
this discussion about somehow obfuscating the AST dump is so completely
absurd. My guess is that DragonEgg does exactly what you
describe. Richard chose to not respond to this fact.

Not quite. DragonEgg is actually a GCC plugin, so, rather than reading a GIMPLE dump, it gets the data from memory and splices the LLVM backend into the GCC compiler process. It is GPL. Any parts of LLVM it uses have to be licensed compatibly with GPL terms. So DragonEgg can't (directly) use a nonfree backend with GCC, although it can dump LLVM IR which could then be fed into a non-free backend, but distributing such a system would have the legal uncertainties of whether you really can obey that particular letter while flagrantly violating the associated spirit. From what I understand, Apple was considering something like that, but decided that developing Clang from scratch was a better idea.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]