Re: Imporved cons representatoin in guile

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

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

I managed to push the send button prematurey,

Here is the code i think that would be needed
SCM SCM_CAR(SCM x)
   SCM *pt = GET_REFERENCE(x)
   scm_t_bits val = SCM_UNPACK(*pt) & SCM/2; (Mask out the first half)
   if(1 & val == 0) //THIN
      {
          if(val & 6 == 0) //non emediate e.g. a pointer
            {
                int64 delta = promote_signed_ptr(val);
                return UNREF(pt + delta);
            }
          if(val & 2 == 1)   // integer
            {
                SCM_PACK(return promote_signed(val))
            }
           return SCM_PACK(val)
      }

     fat version of SCM comes here.

To note is that indeed we do get a more complex code here. But on the other
hand the extra logic is bit twiggelin and compiled using the cpu registers
only at most
a SCM_CAR will take twice the time. A SCM_CDR on the other hand need to
take in two SCM and is probably as fast or faster.

On Fri, Jul 10, 2015 at 1:20 PM, Stefan Israelsson Tampe <
stefan.itampe@gmail.com> wrote:

> 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: 4725 bytes --]