[BDW-GC] Static allocation of subrs

[ludo@gnu.org (Ludovic Courtès)]

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).

     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.

  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 ()').

     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'.

     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...).

The good news is that it actually works.  :-)

I ran `gcbench.scm' with both BDW-GC branches and didn't observe any
significant difference.  The benefits are that (i) initialization should
be slightly faster, and (ii) running several instances of guile should
consume less memory since statically allocated data can be mapped
read-only by the loader and, consequently, the underlying physical
memory can be shared across instances.

Thanks,
Ludo'.

[0] http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=2ee5aa25dbd679b175707762f5961585027e1397
[1] http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=46f9baf49a8ea4461e8494c75a88b87d0f5c5195