Re: uniform-vector?

[Dirk Herrmann]

On Fri, 20 Apr 2001, Masao Uebayashi wrote:

> It would be (realy) nice if I can help this improve, but no idea if I
> can't do it. Okay, I'm trying to read unif.c and learn things around
> it. And please give me the thoughts if you don't mind your thoughs may
> be in vain. ;-)

The core idea is to change the representation of uniform vectors.  My
suggestion is, to keep uniform boolean vectors as a separate datatype, but
to unify the handling of all other uniform vector types.  You will find
that the set of accessor macros is already split between the two:  There
are macros SCM_UVECTOR_* and SCM_BITVECTOR_*.

The representation of SCM_BITVECTORs can be quite simple:  The cell word
#0 holds the type information and the length, cell word #1 holds the
pointer to the memory.  It could make sense to choose a double-cell
representation in order to increase the maximum length.  Such a
representation would allow for other advanced features, like storing some
bit that tells whether the whole vector has been inverted and such.  But,
for the beginning, it is not necessary to think of such things.

The representation of SCM_UVECTORs needs a double cell representation:  
cell word #0 holds the type representation.  We should use one common tc7
code (currently, every single uniform vector type uses a tc7 code of its
own).  The remaining bits of cell word #0 are used to determine the
specific type of uniform vector.  Cell word #1 would store the length of
the vector, and cell word #2 the base address of the corresponding memory
region.

Type specific behaviour can be realized, for example, by providing some
means to 'virtualize' uniform vector handling, like it is done with smobs.  
Assume that for every uniform vector type there is a descriptor like:

  typedef struct scm_uvector_descriptor
  {
    char *name;
    scm_sizet element_size;
    int (*print) (SCM self);
    SCM (*get_element) (void *element);
    void (*set_element) (void *element, SCM value);
  } scm_uvector_descriptor;

Then, for every specific type of a uniform vector the corresponding
functions and values would be filled in.  In contrast to smobs, the
uniform vectors (as they are currently used) don't need mark and free
functions, since there is only raw data stored in them, i. e. no
references to other scheme objects.  One could think of extending this
scheme to allow for all possible kinds of elements to be stored in
uniform vectors, but for the moment the above should be sufficient.

A possible optimization was to store the element size directly in cell
word #0 of an uniform vector object.  This would safe some memory
accesses.

The above is not perfectly thought out (otherwise the code was already
there :-) but it might be a good start.  Maybe it's all obvious anyway.

Best regards,
Dirk Herrmann