guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BDW-GC] Static allocation of subrs


From: Neil Jerram
Subject: Re: [BDW-GC] Static allocation of subrs
Date: Mon, 02 Feb 2009 21:48:30 +0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

address@hidden (Ludovic Courtès) 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 = 6
>      words; with the patch, a subr consumes one double cell and 2 words
>      for `meta_info', i.e., 4 + 2 = 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=guile.git;a=commitdiff;h=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 = 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=guile.git;a=commitdiff;h=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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]