From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: [BDW-GC] Static allocation of subrs Date: Mon, 02 Feb 2009 21:48:30 +0000 Message-ID: <87wsc8jys1.fsf@arudy.ossau.uklinux.net> References: <87vdrv179q.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1233611380 23176 80.91.229.12 (2 Feb 2009 21:49:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Feb 2009 21:49:40 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Feb 02 22:50:54 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LU6gf-0002RM-D9 for guile-devel@m.gmane.org; Mon, 02 Feb 2009 22:50:37 +0100 Original-Received: from localhost ([127.0.0.1]:34745 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LU6fM-0005Iw-Ov for guile-devel@m.gmane.org; Mon, 02 Feb 2009 16:49:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LU6em-00056O-2k for guile-devel@gnu.org; Mon, 02 Feb 2009 16:48:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LU6el-00055i-0J for guile-devel@gnu.org; Mon, 02 Feb 2009 16:48:39 -0500 Original-Received: from [199.232.76.173] (port=45211 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LU6ek-00055X-Sh for guile-devel@gnu.org; Mon, 02 Feb 2009 16:48:38 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]:51733) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LU6ei-0002tW-6R; Mon, 02 Feb 2009 16:48:36 -0500 Original-Received: from arudy (host86-157-180-39.range86-157.btcentralplus.com [86.157.180.39]) by mail3.uklinux.net (Postfix) with ESMTP id 89E2E1F6771; Mon, 2 Feb 2009 21:48:31 +0000 (GMT) Original-Received: from arudy.ossau.uklinux.net (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id A660338013; Mon, 2 Feb 2009 21:48:30 +0000 (GMT) In-Reply-To: <87vdrv179q.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Sat\, 31 Jan 2009 22\:43\:13 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8118 Archived-At: ludo@gnu.org (Ludovic Court=E8s) writes: > Hello! > > The `bdw-gc-static-alloc' branch now contains an implementation of > statically allocated subrs. This was done in 2 steps: > > 1. Using double-cells instead of single-cells for subrs [0]. The > patch is quite nice in that it simplifies `procs.[ch]'. This > change is needed so that subrs don't contain a subr entry number > allocated at run-time (the subr entry number is the index of the > subr in the subr table). I agree that this is a nice improvement. > It does not introduce any storage overhead: previously, a subr > consumed one cell and sizeof (scm_t_subr_entry), i.e., 2 + 4 =3D 6 > words; with the patch, a subr consumes one double cell and 2 words > for `meta_info', i.e., 4 + 2 =3D 6. > > The change leaves the 24 MSBs of the first word of the cell unused. > We might want to do something smart with all these bits. > > For these reasons, we may want to merge this patch in `master' as > well. Yes, I think so. > 2. The second step does the actual work [1]. Currently, it only > deals with subrs, i.e., primitive procedures with "relatively few" > arguments (see `create_gsubr ()'). Presumably that is in practice almost all of the primitives, though? > To distinguish subrs (few arguments) from gsubrs (unrestricted > arity, see `default:' in `create_gsubr ()'), a Dirty Hack(tm) was > needed. The hack is that `SCM_DEFINE' is an alias for a new macro > `SCM_DEFINE_SUBR_reqX_optY_rstZ', where X, Y and Z are the number > of required, optional and rest arguments. If X, Y and Z are such > that a raw subr can be used, then the macro is an alias for > `SCM_DEFINE_SUBR', which does the actual static allocation; > otherwise, it's an alias for `SCM_DEFINE_GSUBR', which is the same > as `SCM_DEFINE' in `master'. Not so bad, IMO. > The dirtiest part of the hack is the generation of "snarf-gsubr.h" > which contains definitions of `SCM_DEFINE_SUBR_reqX_optY_rstZ' for > a "reasonable" number of combinations of X, Y and Z (C++ template > specialization would solve this problem much more elegantly...). This part is quite dirty, as you say. I'm not sure what's the advantage of the generation at make time. Wouldn't it be simpler, and have the same function, just to hardcode all these definitions directly in snarf.h? > [0] http://git.savannah.gnu.org/gitweb/?p=3Dguile.git;a=3Dcommitdiff;h=3D= 2ee5aa25dbd679b175707762f5961585027e1397 Should probably remove the comments about how many subrs there are, since it's no longer relevant. I see there's no NEWS in the commit; is that because there's no impact on the API? Even if so, I imagine it might merit a line in the 2.0 release notes. If you agree, I'd encourage you to write the NEWS now, rather than adding it later. + meta_info =3D scm_gc_malloc (2 * sizeof (* meta_info), + "subr meta-info"); I found the space between "*" and "meta_info" confusing for a few seconds, so would have a preference for "*meta_info". > [1] http://git.savannah.gnu.org/gitweb/?p=3Dguile.git;a=3Dcommitdiff;h=3D= 46f9baf49a8ea4461e8494c75a88b87d0f5c5195 Why does the macro code sometimes use scm_i_paste, and sometimes ## directly? Finally SCM_SUBR_ARITY_TO_TYPE... The implementation feels a bit messy, but I don't have any alternative to suggest, so I guess that's OK. But what about the fact that it's added to the libguile API? I realize that this is necessary to some extent so that snarf.h can be used by application code - but can we somehow restrict SCM_SUBR_ARITY_TO_TYPE to being used in that context, so that it doesn't become on ongoing constraint for us? Regards, Neil