From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: expansion, memoization, and evaluation... Date: Wed, 04 Dec 2002 18:07:17 -0600 Sender: guile-devel-admin@gnu.org Message-ID: <87wumpe3be.fsf@raven.i.defaultvalue.org> References: <87r8cyh5ec.fsf@raven.i.defaultvalue.org> <87heduh43b.fsf@raven.i.defaultvalue.org> <8765uah1fe.fsf@raven.i.defaultvalue.org> <878yz5fq1l.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1039046895 18358 80.91.224.249 (5 Dec 2002 00:08:15 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Dec 2002 00:08:15 +0000 (UTC) Cc: Dirk Herrmann , guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18JjYl-0004l8-00 for ; Thu, 05 Dec 2002 01:08:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JjYi-0003xs-00; Wed, 04 Dec 2002 19:08:04 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18JjY8-0003sh-00 for guile-devel@gnu.org; Wed, 04 Dec 2002 19:07:28 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18JjY5-0003s4-00 for guile-devel@gnu.org; Wed, 04 Dec 2002 19:07:27 -0500 Original-Received: from n66644228.ipcdsl.net ([66.64.4.228] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JjY4-0003rV-00 for guile-devel@gnu.org; Wed, 04 Dec 2002 19:07:24 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 79DBD124EA; Wed, 4 Dec 2002 18:07:22 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 17CBE4A371; Wed, 4 Dec 2002 18:07:18 -0600 (CST) Original-To: djurfeldt@nada.kth.se In-Reply-To: (Mikael Djurfeldt's message of "Wed, 04 Dec 2002 22:47:34 +0100") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1804 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1804 Mikael Djurfeldt writes: >> and foo is a generic function, and last time through, bar and baz were >> integers, but this time bar and baz are strings. Would the current >> behavior be for goops to check, notice this, and build a new >> "precompiled" invocation for two strings? > > Yes. OK. Now I think I understand. >> (Of course if the guile compiler were implemented targeting C, and if >> guile were to "Depends: gcc", we might be able to use dlopen/dlsym to >> support heavyweight online compilation. > > Yes, yes, yes! FWIW I've actually been playing around with ksi, gcc, and the gcc front-end/back-end stuff more, and there are some interesting possibilities. Imagine if you created a gcc front-end using guile that linked any resulting binaries against libguile. It seems like this would mean you could take a very lazy approach to improving your compiler. At first, you might not do much better than guile does now, just replacing (+ x y) with something like the following (I'm using ksi-like syntax below, but ksi is just a thin wrapper around the native "tree" structure used by all the front ends as input to gcc's code generator): (call scm_add (ref x_4432) (ref y_2231)) but later, as we get smarter about flow analysis, etc. we might be able in some cases to generate: (plus (ref x_4432) (ref y_2231)) which would be *way* faster. (Note that no one should panic -- I'm not about to advocate we jump in this direction right now -- I'm just playing around to see what's possible). One thing I'm not clear on at the moment -- the newer gcc's support -foptimize-sibling-calls, which appears to work even for mutually recursive functions, but I was wondering if there was any chance this could work *across* .o files, or if it only worked within the same object file. Any gcc gurus about? I'm presuming cross-boundary optimized tail calls would likely require non-standard C calling conventions, and AFAIK gcc only supports one calling convention for external functions. Ideally, to be able to generate *really* fast code across .o boundaries, we'd want to be able to generate external function references that use a calling convention that's tail-call friendly, and I'm not sure that's possible yet, or even planned. One other interesting possibility for a guile compiler as a gcc front end would be the possibility of either embedding a copy of gcc's C parser at guile compiler build time (or perhaps just adding hooks into the existing gcc parser if the upstream were amenable) so that we can do *real* C code preprocessing -- i.e. automatically extract C function signatures for wrapper generation at compile time, add precice gc annotations, or whatever (i.e. perhaps some of the facinating stuff Tom Lord has suggested). (Hmm I may have already mentioned some of this stuff -- I can't remember whether I that was here or in other private conversations :/) > Maybe I shouldn't reveal this :), but I've seen the current goops as a > large-scale experiment to test whether these crazy ideas really work > in practise. And they actually seem to. I've made heavy use of goops > in large systems consisting of maybe 50 modules, and I don't have any > complaints on its performance. Interesting. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel