From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jacob Bachmeyer Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Mon, 12 Jan 2015 17:21:21 -0600 Message-ID: <54B456F1.4060706@gmail.com> References: <54B1B97E.9070204@gmail.com> <87fvbhskl5.fsf@engster.org> Reply-To: jcb62281@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1421104902 31677 80.91.229.3 (12 Jan 2015 23:21:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Jan 2015 23:21:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 13 00:21:36 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YAoIh-0002Vs-PB for ged-emacs-devel@m.gmane.org; Tue, 13 Jan 2015 00:21:36 +0100 Original-Received: from localhost ([::1]:36678 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAoIg-0006z6-QX for ged-emacs-devel@m.gmane.org; Mon, 12 Jan 2015 18:21:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAoIb-0006xu-9r for emacs-devel@gnu.org; Mon, 12 Jan 2015 18:21:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAoIW-0005fV-Bt for emacs-devel@gnu.org; Mon, 12 Jan 2015 18:21:29 -0500 Original-Received: from mail-oi0-x232.google.com ([2607:f8b0:4003:c06::232]:37691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAoIW-0005fR-6I for emacs-devel@gnu.org; Mon, 12 Jan 2015 18:21:24 -0500 Original-Received: by mail-oi0-f50.google.com with SMTP id x69so22902640oia.9 for ; Mon, 12 Jan 2015 15:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9j52F+3JkgaM8sNfn+fT3boGqt5+tAdqQ1xT/OQLPR8=; b=Y90BndOt5aJQi8QHSXN/0PhWmlj+2CttuEpuAn7/CC7aNQCjkRfC9A1hwEKyhHn9V4 e/dNR1EcVnbnj6LkKXeHm/06g4vS5YqslSXiNSkCil8XIzbXWRpKfw4mH+Qi9bPFJUg1 SEBXn2G99AXxtcfbRzip+CNwzqGjHrOPBmuQFKgpx6Q80BlcXmOkcdek70ddUDIkrRDT aN+qGcrGhE/sJGooPEj/5Th/nMTFFRhPSVyINojXpRqWwDCUk85OiUcCUslAl08DBSAx Pfqfxbs2AB92UsS9+Vrn0Xiy9EEbpC9DmawREc6d4PvH1ltvlCD/bwl0ByxZ0+PPILL0 VjOg== X-Received: by 10.182.153.39 with SMTP id vd7mr19198607obb.78.1421104883657; Mon, 12 Jan 2015 15:21:23 -0800 (PST) Original-Received: from [192.168.2.42] (adsl-70-133-148-241.dsl.ablntx.sbcglobal.net. [70.133.148.241]) by mx.google.com with ESMTPSA id mm9sm9719841obb.6.2015.01.12.15.21.22 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Jan 2015 15:21:23 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 In-Reply-To: <87fvbhskl5.fsf@engster.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c06::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:181198 Archived-At: 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.