[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The relationship between SCM and scm_t_bits.

From: Dirk Herrmann
Subject: Re: The relationship between SCM and scm_t_bits.
Date: Sat, 15 May 2004 17:00:12 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040220

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

 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]