From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: next steps. Date: Tue, 11 Dec 2018 11:34:21 +0000 Message-ID: <20181211113420.GB4911@ACM> References: <20181210180033.GC4188@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1544528269 3050 195.159.176.226 (11 Dec 2018 11:37:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2018 11:37:49 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 11 12:37:45 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gWgMC-0000gi-Ue for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 12:37:45 +0100 Original-Received: from localhost ([::1]:37585 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWgOJ-0000Fd-NT for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 06:39:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWgOE-0000EU-H0 for emacs-devel@gnu.org; Tue, 11 Dec 2018 06:39:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWgO9-0007yG-Iw for emacs-devel@gnu.org; Tue, 11 Dec 2018 06:39:50 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:51093 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gWgO7-0007k9-MG for emacs-devel@gnu.org; Tue, 11 Dec 2018 06:39:45 -0500 Original-Received: (qmail 97186 invoked by uid 3782); 11 Dec 2018 11:39:40 -0000 Original-Received: from acm.muc.de (p2E5D5A02.dip0.t-ipconnect.de [46.93.90.2]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 11 Dec 2018 12:39:39 +0100 Original-Received: (qmail 5214 invoked by uid 1000); 11 Dec 2018 11:34:21 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:231753 Archived-At: Hello, Paul. On Mon, Dec 10, 2018 at 15:54:02 -0800, Paul Eggert wrote: > On 12/10/18 10:00 AM, Alan Mackenzie wrote: > > lisp.h would be modified to define alternative versions of EQ, NILP, > > SYMBOLP, and XSYMBOL, and alternative versions of the INLINE functions > > which call them. These would be called BC_EQ, BC_NILP, BC_SYMBOLP, and > > BC_XSYMBOL. > > Most of the C sources would, at build time, be fed to a preprocessor > > which would analyse (almost every) C function, and write a temporary file > > containing the functions foo and BC_foo next to eachother. > This preprocessor would be a separate program that we'd write? Yes. > If so, that sounds error-prone. C is notoriously tricky to > preprocess, ... You don't need to tell me that. ;-) However, all this preprocessor would do would be to recognise starts and ends of functions from a list of known functions, and textually substitute BC_foo for foo, again from that list of known substitutions. It would need to parse comments and strings. The list of known functions can be reliably generated by objdump (from binutils). This preprocessor would be tedious rather than difficult to write. > .... and Emacs already uses the C preprocessor aggressively. Instead, > why not use the C preprocessor itself, rather than writing another > preprocessor for C? In other words, compile each file twice, once with > one -D option and once with another. Because the two interpreters will need to share file static data, of which there must be only one copy. So the two versions of each function need to be in the same "source" file. The approach has the advantage that only minimal amendment of the C source, if that, will be needed. > Even with this suggestion, though, I'm leery of multiple interpreters. > Although it'd be better to have multiple interpreters (one faster, one > slower) than to have just a single, slower interpreter, it'd be better > yet to have just a single, faster interpreter. Yes, we'd all like that, but several weeks of exploring alternatives has failed to produce any workable solutions on these lines. > Instead, I suggest looking into Stefan's suggestion to use edebug info > , > which should be a much less-drastic way to address the problem; Not really, no. To recap, that would involve the reader adding annotations to every Lisp element, turning it into a list looking like: (locinfo FILE POS (foo (locinfo FILE POS a) (locinfo FILE POS 4))) in place of (foo a 4) . The form Stefan suggested is MUCH bigger than the plain form, having, perhaps four times the number of conses (I haven't counted them). A large part of the compiler would need to be amended to cope with the new format, even supposing it could work with macros (which I don't think it could). This amendment would be uninspiring and tedious in the extreme. I seriously doubt this would run faster than the symbols-with-position approach (which has already been implemented), even if it could be made to work. > for more info, see Gemini's followup > . I've read this several times. It suffers the same drawbacks as Stefan's idea. In particular it doesn't give any idea how the compiler would operate on the proposed forms. > Alternatively, Yuri's suggestion of an opt-in property for macros > also seems > like a much-simpler approach that should work just as well in the long > run as multiple interpreters would. I don't think it would work, either. That idea is for macros' uses of eq to be replaced by BC-eq inside the macro. The trouble is, many uses of eq are actually expansions of EQ in the C code (e.g. in Fequal, Fassq, ....) and they would all need modifying too, and we're back in the same situation of having an alternative interpreter. -- Alan Mackenzie (Nuremberg, Germany).