From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Thu, 20 Feb 2014 22:45:29 -0500 Message-ID: References: <83d2iqc84m.fsf@gnu.org> <87wqgxkcr9.fsf@yandex.ru> <834n41db0d.fsf@gnu.org> <52FE2985.4070703@yandex.ru> <831tz5daes.fsf@gnu.org> <8738jlohd6.fsf@yandex.ru> <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <87wqgr4v18.fsf@yandex.ru> <53064BD0.7070009@yandex.ru> <87ha7tr5bo.fsf@fencepost.gnu.org> <87ppmhecd8.fsf@yandex.ru> <8761o9jq8n.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf301af7fdfed8ce04f2e273da X-Trace: ger.gmane.org 1392954332 14381 80.91.229.3 (21 Feb 2014 03:45:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Feb 2014 03:45:32 +0000 (UTC) Cc: Dmitry Gutov , Emacs developers To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 21 04:45:41 2014 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 1WGh3V-0000HL-2Q for ged-emacs-devel@m.gmane.org; Fri, 21 Feb 2014 04:45:41 +0100 Original-Received: from localhost ([::1]:41832 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGh3U-00011E-Nu for ged-emacs-devel@m.gmane.org; Thu, 20 Feb 2014 22:45:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGh3N-000116-N6 for emacs-devel@gnu.org; Thu, 20 Feb 2014 22:45:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGh3M-0006BJ-CX for emacs-devel@gnu.org; Thu, 20 Feb 2014 22:45:33 -0500 Original-Received: from mail-yk0-x22d.google.com ([2607:f8b0:4002:c07::22d]:34167) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGh3K-0006B0-57; Thu, 20 Feb 2014 22:45:30 -0500 Original-Received: by mail-yk0-f173.google.com with SMTP id 10so4400817ykt.4 for ; Thu, 20 Feb 2014 19:45:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1vN6uJ75M81Qdt5G8M3f/zReJCLcl8Xd3fgWchrjAhI=; b=KxdzAVlVUlqIbDfr9gApyMoQFOSNHc3Lc7XB5aImhEr0uz6uh025Odx0t+mQDZZERe 54fvrXlgg6ieh0sNUAo764jpi3m2PvwTaZG84BqNop3s7373ONI8C/hNqu4eku7+S8Rd vanPRwe/6/xX1hXh0at3no4ZvaGiKaquJ0+LvSZlhcWgf8TkNzSxsDynyGKczOi2YhGr MC3hN8loJON+Ko1/PqsPSzSO/U4Ae8I2VCpSVV2CL0p8WdBmKTvYgzHqISPN6gg7z9UV DPth18Z8hJZ59t437N/S2zUJV/zU0UdVgPp8wO5em44iRt/Hk16irza1A1BhMiLU5JpM syrQ== X-Received: by 10.236.114.71 with SMTP id b47mr8262237yhh.42.1392954329453; Thu, 20 Feb 2014 19:45:29 -0800 (PST) Original-Received: by 10.170.46.138 with HTTP; Thu, 20 Feb 2014 19:45:29 -0800 (PST) In-Reply-To: <8761o9jq8n.fsf@fencepost.gnu.org> X-Google-Sender-Auth: beP8UAJ5-Wm8YESNMr3ODf1zsbA X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c07::22d 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:169797 Archived-At: --20cf301af7fdfed8ce04f2e273da Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 20, 2014 at 6:53 PM, David Kastrup wrote: > > My guess is that switching off optimization, you'd not be all that bad. > I already assumed that a magic "give me completions" flag would turn off optimization and code generation. I am concerned about process startup, I/O (even if the required headers are already in the block cache), lexing, parsing and semantic analysis. Remember, we are talking C++ here, not C. Trivial programs pull in mega headers (stl, boost, etc) with increasing use of such wonderful language features as "Turing-complete template meta-programming". "Fails to acknowledge" is not the same as "is not going to accept". > Let me state that more clearly. Correct me if I am wrong but I believe that RMS has never done any C++ development. As such he has little appreciation for the value C++ developers may attach to tools with deep knowledge of C++ semantics. Well, given the right article author. If we are talking about the > conclusions of Phoronix, see > http://draketo.de/light/english/free-software/phoronix-distort-results-gcc-llvm-clang-amd-vishera > >. > I used the word "competing" to mean "offering similar service or functionality". I did not intend to bring in any notion of relative performance of generated code. Splitting parser and code generator into separately > usable components... That is not the issue. Given that the gcc backend can be linked with a number of different frontends I assume that stubbing off a few functions would provide a free-standing frontend. OTOH if gcc wants to "compete" with clang in the tools space it will have to provide interfaces for querying and manipulating its symbol table and intermediate representation. That is some rather heavy lifting for a codebase not designed from the outset with that goal in mind > Even when that has been done, one still has to do an actual > implementation and _then_ have to see whether under the constraints of > the current implementation the hoped-for advantages are actually as > envisioned, and the accepted drawbacks don't turn out larger than > expected. And there is not much of an option to turn back the clock, > either. > Do I understand you correctly here? Did you just conceded my original point, namely that while RMS does not want us to dissipate the pent up demand that could drive gcc into the tool space, that transformation most likely will never happen? IOW emacs-based C++ developers are denied valuable tools that are becoming ever more common in other development environments based on a chimera. /john --20cf301af7fdfed8ce04f2e273da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 20, 2014 at 6:53 PM, David Kastrup <dak@gnu.org> wrote: My guess is that switching off optimization, you'd not be all that bad.=

I already assumed that a magic "g= ive me completions" flag would turn off optimization and code generati= on. =A0I am concerned about process startup, I/O (even if the required head= ers are already in the block cache), lexing, parsing and semantic analysis.= =A0Remember, we are talking C++ here, not C. =A0Trivial programs pull in m= ega headers (stl, boost, etc) with increasing use of such wonderful languag= e features as "Turing-complete template meta-programming".

"Fails to acknowledge&= quot; is not the same as "is not going to accept".

Let me state that more clearly. =A0C= orrect me if I am wrong but I believe that RMS has never done any C++ devel= opment. =A0As such he has little appreciation for the value C++ developers = may attach to tools with deep knowledge of C++ semantics.

Well, given the right artic= le author. =A0If we are talking about the
conclusions of Phoronix, see
<URL:http://draketo= .de/light/english/free-software/phoronix-distort-results-gcc-llvm-clang-amd= -vishera>.

I used the word "competing" to m= ean "offering similar service or functionality". =A0I did not int= end to bring in any notion of relative performance of generated code.

Splitting parser and code generator into se= parately
usable components...

That is not the issue.= =A0Given that the gcc backend can be linked with a number of different fro= ntends I assume that stubbing off a few functions would provide a free-stan= ding frontend. =A0OTOH if gcc wants to "compete" with clang in th= e tools space it will have to provide interfaces for querying and manipulat= ing its symbol table and intermediate representation. =A0That is some rathe= r heavy lifting for a codebase not designed from the outset with that goal = in mind
=A0
Even when that has been done, one still has = to do an actual
implementation and _then_ have to see whether under the constraints of
the current implementation the hoped-for advantages are actually as
envisioned, and the accepted drawbacks don't turn out larger than
expected. =A0And there is not much of an option to turn back the clock,
either.

Do I understand you correctly h= ere? =A0Did you just conceded my original point, namely that while RMS does= not want us to dissipate the pent up demand that could drive gcc into the = tool space, that transformation most likely will never happen? =A0IOW emacs= -based C++ developers are denied valuable tools that are becoming ever more= common in other development environments based on a chimera.

/john
--20cf301af7fdfed8ce04f2e273da--