[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

reply via email to

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