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: scratch/accurate-warning-pos: next steps. Date: Mon, 10 Dec 2018 18:00:33 +0000 Message-ID: <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 1544465076 17497 195.159.176.226 (10 Dec 2018 18:04:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 10 Dec 2018 18:04:36 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 10 19:04:32 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 1gWPuu-0004Kv-TX for ged-emacs-devel@m.gmane.org; Mon, 10 Dec 2018 19:04:29 +0100 Original-Received: from localhost ([::1]:34131 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWPx1-000436-0L for ged-emacs-devel@m.gmane.org; Mon, 10 Dec 2018 13:06:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWPwM-00042z-Ge for emacs-devel@gnu.org; Mon, 10 Dec 2018 13:05:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWPwI-0007M7-Bg for emacs-devel@gnu.org; Mon, 10 Dec 2018 13:05:58 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:56254 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gWPwH-0007Ji-WB for emacs-devel@gnu.org; Mon, 10 Dec 2018 13:05:54 -0500 Original-Received: (qmail 666 invoked by uid 3782); 10 Dec 2018 18:05:47 -0000 Original-Received: from acm.muc.de (p2E5D5AF9.dip0.t-ipconnect.de [46.93.90.249]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 10 Dec 2018 19:05:47 +0100 Original-Received: (qmail 8770 invoked by uid 1000); 10 Dec 2018 18:00:33 -0000 Content-Disposition: inline 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:231741 Archived-At: Hello, Emacs. Here's my scheme for making further progress on the scratch/accurate-warning-pos branch. At the moment, it appears to display the requisite accurate source positions in warning messages, but it slows Emacs down a little. Hence it has not been accepted in its current form. Following an idea from Paul, I propose to build an alternative byte-code interpreter alongside the primary one. This second interpreter would regard symbols with position as being EQ to the corresponding bare symbols, just as the branch currently does when symbols-with-pos-enabled is bound to non-nil. C symbols in components of the second interpreter would be those of the main one, prefixed by "BC_". 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. foo would be unchanged from the C source, BC_foo would have calls to bar modified to BC_bar, and invocations of EQ etc., modified to BC_EQ, etc. These preprocessor outputs would be compiled into temacs in place of the primary C sources. The resulting temacs would, of course, be bigger than the current temacs. In particular, the byte code interpreter exec_byte_code in bytecode.c would have its alternative BC_exec_byte_code. The struct Lisp_Subr would be amended to hold three Lisp_Functions - the currently live one, the normal one, and the BC_... one. Also a next pointer would be introduced, chaining all the subrs together. The .el and .elc files would not require amendment (apart from bytecomp.el, and so on, of course). When a byte compilation is initiated, the compiler would replace the current live function field with the corresponding BC_ function in every Lisp_Subr, thus switching over to the BC_... interpreter. At termination of the compiler, an unwind-protect would restore the Lisp_Subrs to their standard settings. There remains the question, which C functions would get a BC_... version? To begin with, I propose almost every C function. Only those for which a second version would be damaging (for example, the command loop) would remain unique. Once the mechanism is working, we could steadily reduce the number of BC_... functions from "as many as possible" to "what is needed ". For example, surely xdisp.c, and xterm.c would not need duplication. This scheme would allow accurate warning line numbers to be output, whilst not slowing down the normal operation of Emacs. It would likely slow down the operation of the byte compiler by several per cent, as has been measured in the current scratch/accurate-warning-pos branch. Comments? -- Alan Mackenzie (Nuremberg, Germany).