Imporved cons representatoin in guile

[Stefan Israelsson Tampe <stefan.itampe@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

Hi,

I was complentating the cons cells in guile an was wondering if we could
pack our cons cells better than today. So this is some notes about this.

Currently if x is a cons cell we have the relation
x -> [SCMCAR,SCMCDR]

This is really neat and makes guiles conses quite compact e.g. a vector y
of two elements is
y -> [SCMTAG,SCMV1,SCMV2], where SCMTAG containes the datatype tag and
length of the
vector.

To compress even further we need a way to could use
x ->[SCM/2/SCM/2], witt SCM/2 the same tagging half the size as the normal
SCM with the interpretation that if
SCM/2 is a non emediate then it starts with 00 and is then interpreted as a
signed integer i and the real adress is x + i, e.g. a relative adress
regarding.

We of cause must also add a fat cons cell of the form
x -> [Tag,X,Y] for the case when SCM/2 is not fitting. Currently I can't
see this beeing common. But
if we later makes floating point represented via nan boxing e.g. stored
directly in a 64bit value then
the cons cell will be mostly fat and there would be a speed reduction using
cons cells. On the other hand there has been a considerable speed.

There is a final sematic case that needs to be fixed. if we do a setcar on
a thin cons cell and the cell
then becomes fat, we need to create the following

x -> oldthin -> newfat

e.g. we need to add a pointer type with the meaning of automatically follow
the pointer if we encounter it. then oldthin is also tagging a variant of a
cons cell. It is possible to keep it slim
in the code that all fat cons cells is represented like that.

How would a SCM_CAR be like?

SCM SCM_CAR(SCM x)
   if(THIN(x))
      {

      }

[-- Attachment #2: Type: text/html, Size: 2179 bytes --]