[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: |
Marius Vollmer |
Subject: |
Re: The relationship between SCM and scm_t_bits. |
Date: |
Mon, 17 May 2004 21:22:03 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
Dirk Herrmann <address@hidden> writes:
> I have not yet given it a try, but I found the suggestion to use a
> union quite appaling:
[ I think you mean "appealing". :-) I used to mix up the adjectives
"content" and "contempt"... [ And its "appalling" with double-el.
I hope you don't mind this little public correction. [ I think I
can get away with it since I make a ton of mistakes myself... ] ]
]
> [...]
>
> typedef struct scm_t_cell
> {
> union {
> scm_t_bits word;
> SCM object;
> } elements[];
> } scm_t_cell;
Yes, but consider how we use the heap: we fetch a word and then must
decide whether it is a SCM or a scm_t_bits, we don't know this in
advance in every case. This is not really supported by a union: I
don't think you can store into one member and then (portably) assume
anything about the value read from a different member. This is very
much like storing into one memory location thru one pointer and
reading that same location through a differently-typed pointer. I
therefore don't think that using a union is an improvement.
(It will work on all 'normal' platforms, of course, just like casting
the pointers worked, but I would like to get away from relying on this
non-portable behavior.)
Thus, I think we are better off by just declaring the heap words to be
of type SCM and always accessing them as this type. Converting
between SCM and scm_t_bits will happen with SCM_PACK and SCM_UNPACK.
That way, we don't need to assume that a SCM and a scm_t_bits are
stored identically in memory.
(And incidentally, we don't use scm_t_cell that much in Guile anyway.
We should maybe remove it. I tried recently but didn't finish since
it turned out to be quite some amount of work to get all size
statistics in the GC correct.)
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
- 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, 2004/05/15
- 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 <=
- 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