Re: The relationship between SCM and scm_t_bits.

[Dirk Herrmann <dirk@dirk-herrmanns-seiten.de>]

Marius Vollmer wrote:

>  I propose to remove the need to convert between scm_t_bits* and SCM*
>  and to allow only SCMs to be in memory.
>
>
>  The words in a scm_t_cell would be of type SCM. This would mean that
>  SCM_CELL_WORD_LOC would be removed and replaced with
>  SCM_CELL_OBJECT_LOC. Also, SCM_SET_SMOB_DATA (etc) might not be able
>  to store all scm_t_bits values that it is handed (because scm_t_bits
>  could be larger than a pointer). We could make a new guarantee that
>  says that SCM_SET_SMOB_DATA (etc) can store any pointer that is cast
>  to a scm_t_bits and any integer that fits into 'unsigned int', say.
>
>  The type scm_t_bits would be restricted to temporary values that are
>  mostly used to test tag bits etc. They would usually not stored in
>  data structures and when they are, they can not be expected to
>  protected the SCM value that they encode when they are scanned
>  conservatively.
>
>  Should we (gradually and with deprecation and everyhing) remove
>  scm_t_bits from the smob API completely? I have not thought this
>  thru, but we might and with something that is not really an
>  improvement, just different.

I have tried to give it some more thought:

Since the introduction of scm_t_bits, it has been stated about SCM 
variables,
that every SCM variable is known to hold a valid scheme object, while 
scm_t_bits
variables may also hold arbitrary data.

On the heap, however, cells do typically _not_ hold valid scheme 
objects. One of
the exceptions is the pair object, which has the property, that both of
its cell entries happen to hold valid scheme objects. This is the reason why
SCM_CARLOC and SCM_CDRLOC work on pairs. If you use SCM_CARLOC or
SCM_CDRLOC on anything else than a pair object, you will most likely crash
the system, because the SCM value that you get will not hold a valid scheme
object.

 From this perspective, it is inconsistent to define scm_t_cell to hold 
SCM objects.


I have not yet given it a try, but I found the suggestion to use a union 
quite appaling:

typedef struct scm_t_cell
{
  union {
    scm_t_bits word_0;
    SCM object_0;
  } element_0;
  union {
    scm_t_bits word_1;
    SCM object_1;
  } element_1;
} scm_t_cell;

or even a more generic version, which would cover single cells as well 
as double
cells and even allow to cleanly iterate over all cell elements in a loop:

typedef struct scm_t_cell
{
  union {
    scm_t_bits word;
    SCM object;
  } elements[];
} scm_t_cell;

I see no reason why either of the above solutions should have a negative
influence on performance. All of our cell accessing macros should be easily
re-definable with those types, in particular:

#define SCM_GC_CELL_WORD(x, n) (((SCM2PTR (x)) [n]).word)
#define SCM_GC_CELL_OBJECT(x, n) (((SCM2PTR (x)) [n]).object)

which does not require any casting to be performed any more :-)

Best regards,
Dirk Herrmann




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel