From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Compiling Elisp to a native code with a GCC plugin Date: Tue, 14 Sep 2010 16:13:53 -0700 Message-ID: <1284506033.2446.11.camel@dell-desktop.example.com> References: <87bp805ecr.fsf@gmail.com> <874ods5ctf.fsf@gmail.com> <877hio3urh.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1284506113 7449 80.91.229.12 (14 Sep 2010 23:15:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Sep 2010 23:15:13 +0000 (UTC) Cc: Wojciech Meyer , emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 15 01:15:11 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OveiV-0001bm-3J for ged-emacs-devel@m.gmane.org; Wed, 15 Sep 2010 01:15:11 +0200 Original-Received: from localhost ([127.0.0.1]:48508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OveiU-0003ol-4s for ged-emacs-devel@m.gmane.org; Tue, 14 Sep 2010 19:15:10 -0400 Original-Received: from [140.186.70.92] (port=53253 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvehM-0003mI-6b for emacs-devel@gnu.org; Tue, 14 Sep 2010 19:14:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OvehK-0004RQ-Qt for emacs-devel@gnu.org; Tue, 14 Sep 2010 19:14:00 -0400 Original-Received: from smtp131.iad.emailsrvr.com ([207.97.245.131]:59085) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvehK-0004RJ-Oa for emacs-devel@gnu.org; Tue, 14 Sep 2010 19:13:58 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp43.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 0CDBF2D020D; Tue, 14 Sep 2010 19:13:58 -0400 (EDT) X-Virus-Scanned: OK Original-Received: by smtp43.relay.iad1a.emailsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 645192D01E4; Tue, 14 Sep 2010 19:13:57 -0400 (EDT) In-Reply-To: X-Mailer: Evolution 2.28.3 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:130160 Archived-At: I've only loosely followed this thread so its possible I'm off the mark (in which case - sorry) but, i'm pretty sure it might be helpful to remark about a variant of what I guess Tromey is suggesting: Years ago - not for GC but for managing critical sections wherein interrupts had to be deferred - we did something similar in a fork of GNU Guile. In that case, semi-automated ad-hoc rewriting was used a tiny bit but the most helpful thing turned out to be: a) rip a C grammar out of GCC (unless we used a different source, I forget). b) hack the actions to hook up to a scheme (or other lisp) run-time system and build an AST as a big S-EXP. Make sure this AST records source files and line numbers. c) write ad-hoc cheapo static analysis tools to walk the AST and find places where either it was obvious fixes were needed, or where it was not obvious fixes were not needed --- print those out like compiler error messages. d) Interactively page through those and, as you watch each case, apply the ad hoc semi-automated rewrite tools (or do it by hand in hard cases). Step (d) can go very, very fast and, at least in that case, steps (a .. c) can go a lot faster than you might guess at first glance. -t On Tue, 2010-09-14 at 15:16 -0600, Tom Tromey wrote: > >>>>> "Wojciech" == Wojciech Meyer writes: > > Tom> It could be done. It just requires someone willing to do the work. > > Wojciech> I know. I could get my old sources of generational garbage > Wojciech> collector, to work. However it is a daunting job (the worse I > Wojciech> could imagine, garbage collectors are nasty), plugging and > Wojciech> debugging a new garbage collector to such huge and esoteric (I > Wojciech> am sure people that who've been working on Emacs for years > Wojciech> will not take this words badly and understand straight away > Wojciech> what I am (a newbie) talking about) project like > Wojciech> Emacs. However I might try to experiment with it (however > Wojciech> unfortunately I am not that self confident about it ;) ). > > It is always ok to ask for help. > > The current collector is very simple to understand. If you read > alloc.c, and look through the data structures representing lisp objects > (in lisp.h), you will have a pretty good idea of what is going on. > > > FWIW, I looked at writing an incremental collector for Emacs. I was > primarily interested in using software write barriers... this turns out > to be hard because there is a lot of code in Emacs of the form: > > FIELD_ACCESSOR (object) = value; > > ... which for a software barrier has to be converted to: > > SET_FIELD_ACCESSOR (object, value); > > (There are other bad things, too, like passing around a Lisp_Object* > that points to the contents of a vector.) > > So, lots of grunge work, just to get the point where you could start > actually working on the GC. I would look at automated rewriting to > make this work -- that worked out great on the concurrent branch. > > > There was a more real attempt based on the Boehm GC. I think the bits > from that are still on a branch. This GC has a generational mode that, > IIRC, is based on memory protection bits. > > Tom >