[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
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
- Re: The relationship between SCM and scm_t_bits., (continued)
Re: The relationship between SCM and scm_t_bits., Marius Vollmer, 2004/05/10
Re: The relationship between SCM and scm_t_bits., Dirk Herrmann, 2004/05/15
Re: The relationship between SCM and scm_t_bits.,
Dirk Herrmann <=
- Re: The relationship between SCM and scm_t_bits., Dirk Herrmann, 2004/05/15
- Re: The relationship between SCM and scm_t_bits., Marius Vollmer, 2004/05/17
- Re: The relationship between SCM and scm_t_bits., Paul Jarc, 2004/05/17
- Re: The relationship between SCM and scm_t_bits., Dirk Herrmann, 2004/05/21
- Re: The relationship between SCM and scm_t_bits., Paul Jarc, 2004/05/21
- Re: The relationship between SCM and scm_t_bits., Dirk Herrmann, 2004/05/23
- Re: The relationship between SCM and scm_t_bits., Paul Jarc, 2004/05/23