From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.user Subject: status: separation of expansion/optimization/memoization/execution Date: Sat, 3 Aug 2002 00:42:21 +0200 (CEST) Sender: guile-user-admin@gnu.org Message-ID: <20409.8358670764$1028328162@news.gmane.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1028328162 17872 127.0.0.1 (2 Aug 2002 22:42:42 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 2 Aug 2002 22:42:42 +0000 (UTC) Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17al84-0004e9-00 for ; Sat, 03 Aug 2002 00:42:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17al8S-0005r9-00; Fri, 02 Aug 2002 18:43:04 -0400 Original-Received: from sallust.ida.ing.tu-bs.de ([134.169.132.52]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17al7n-0005qS-00; Fri, 02 Aug 2002 18:42:23 -0400 Original-Received: from localhost (dirk@localhost) by sallust.ida.ing.tu-bs.de (8.9.3+Sun/8.9.1) with ESMTP id AAA05424; Sat, 3 Aug 2002 00:42:21 +0200 (CEST) Original-To: guile-devel@gnu.org, guile-user@gnu.org Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:773 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:773 Hi folks, just wanted to let you know that I have actually been working on the issue above: Currently I am splitting up built-in macros following the following pattern: Former function: SCM scm_m_foo (SCM expr, SCM env) { /* perform syntax checking, expansion, minor optimizations and memoization in one step. */ return ; } New set of functions: static SCM expand_foo (SCM expr, SCM env) { /* perform syntax checking and expansion. After this step, the code is still valid scheme code. However, not all features are used. */ return expanded_expr; } static SCM optimize_foo (SCM expr, SCM env SCM_UNUSED) { /* Most optimization functions are empty upto now. In some cases, minor optimizations are performed. After this step, the code is still valid scheme code. However, not all features are used. */ return optimized_expr; } static SCM memoize_foo (SCM expr, SCM env) { /* return the memoized form of foo. In some cases, minor memoization related optimizations are performed. After this step, the code is not valid scheme code any more, and, with the current printer and reader, it can not be written and re-read. */ return memoized_expr; } SCM scm_m_foo (SCM expr, SCM env) { /* first, call expand_foo. Then, using the result, call optimize_foo. Then, using the result of optimize_foo, call memoize_foo. */ return memoized_expr; } Basically, with the changes above everythings still works as before, that is, expansion and friends are still executed dynamically during execution. However, the functionality of each of the builtin-mmacros is more cleanly separated into different tasks with different responsibilities. And, I have added more exhaustive syntax checks into the expand_foo functions. Up to now I have done this only for "if", "set!", "and", "or", "case", "cond" and "do". I also have simplified SCM_CEVAL at those places, where due to the more extensive syntax checks in expand_foo some execution-time syntax checks could be eliminated. (However, all this takes some time, since I only manage to finish at most one macro each day.) The effect so far is, that booting guile takes noticably longer (at least 15%), but for example executing the test-suite is almost as fast as before (2% slower). Unfortunately, it is not yet possible to achieve large performance improvements. This will only be possible when the steps are really separated. Then, memoizing variable locations in the memoize_foo functions will be possible, which simply can not work at the moment: One reason is the re-writing of internal defines, which disallows the memoization of variables until the expansion phase is completed. I have, however, not taken care of keeping track of debugging information so far. That is, I would like to hear suggestions about how this should be done, since I don't have looked into that issue yet. If someone is interested to give the stuff a review (with respect to the debugging issues or just generally), I would be glad to send you the patches for eval.c and eval.h. If the debugging stuff is worked out, it could even make sense to submit the changes so far to allow for a broader testing in the head branch. Best regards, Dirk Herrmann _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user