[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BDW-GC] Static allocation of subrs
Re: [BDW-GC] Static allocation of subrs
Tue, 03 Feb 2009 00:38:07 +0100
Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)
Note: I reply to messages in order of least difficulty. ;-)
Neil Jerram <address@hidden> writes:
> address@hidden (Ludovic Courtès) writes:
>> For these reasons, we may want to merge this patch in `master' as
> Yes, I think so.
Noted, will do.
>> 2. The second step does the actual work . 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?
That's 200 gsubrs, vs. 873 "simple" subrs.
>> 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.
It breaks cases like primitive procedures with more than 16 arguments
(because I arbitrarily decided that `snarf-gsubr.h' would contain
definitions up to 16 req/opt args), and situations like:
SCM_DEFINE (scm_foo, "foo", 0001, 0002, 0003, ...)
This is probably acceptable in practice.
>> 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?
Given the size of `snarf-gsubr.h' (there are 16 * 16 * 2 = 512
combinations), I'd rather keep it separated. The makefile rule is an
efficient way to compress it. ;-)
> 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.
Right. It's just that I have not maintained any NEWS file for
BDW-GC-related changes, initially.
> + meta_info = 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".
Yes, I feel the same today (I probably felt differently that day). :-)
> Why does the macro code sometimes use scm_i_paste, and sometimes ##
The `scm_i_paste ()' macro is needed so that macro-expansion of
definitions like those of `srfi-4.i.c' work as expected. There are a
few cases where it isn't used (e.g., in `SCM_IMMUTABLE_DOUBLE_CELL ()'),
but I guess it didn't cause any problem because `scm_i_paste ()' was
properly used by callers. We could unify that but `scm_i_paste ()' has
the drawback of having a long name.
> 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
The problem is that this information is shared among 3 places:
`SCM_SUBR_ARITY_TO_TYPE ()', `create_gsubr ()', and
`SCM_DEFINE_SUBR_reqX_optY_rstZ ()'. Ideally, all 3 would be generated
from a single source.
Besides, I think we need to review the use of subr/gsubr tag in detail
to see whether we can make better use of them.
> 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?
I share your concern, but I have no idea of how to avoid it. We could
add `_I_' in its name, perhaps. Hopefully, it's too low-level for
anyone to try it.