Re: The relationship between SCM and scm_t_bits.

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

Marius Vollmer wrote:

>Hi,
>
>I just got confused about our two 'fundamental' types, SCM and
>scm_t_bits.
>
The two types were introduced in order to create a level of abstraction 
between code, that operates on the encoding of scheme types, and code 
that only requires on API elements to do so.  The background was, that 
SCM formerly was just a typedef to "long". This had the disadvantage 
that the compiler did not do proper type checking when dealing with SCM 
types. For example, you could by mistake write "if (some_SCM_value) ..." 
if instead you had intended to write "if (!SCM_FALSEP 
(some_SCM_value))". Guile had a number of bugs of this or a similar type 
at that time. Thus, we wanted to introduce a better type checking, but 
on the other hand be able to deal with the bit representation in low 
level code. Thus the separation into SCM and scm_t_bits.

The idea is, to have SCM normally defined to be some performance 
efficient type, like a pointer to an unknown struct. This will inhibit 
most errors, like passing an integer where a SCM is expected, or 
performing arithmetic operations on a SCM value. It does not, however, 
inhibit the "if (some_SCM_value)" bug, since the compiler will accept a 
pointer there. Thus, from time to time, just for type-checking purposes, 
we can have SCM defined as a struct or union, thus inhibiting even those 
problems. You will find more information about that if you are looking 
at the use of SCM_DEBUG_TYPING_STRICTNESS in tags.h and the explanation 
in __scm.h. Unfortunately, compiling with SCM_DEBUG_TYPING_STRICTNESS 
set to 2 does not compile without errors, due to some tricky problems in 
some files. Nevertheless it should still be quite helpful for most parts 
of guile. Using it, I remember to have fixed about 5 to 10 bugs in guile 
at that time, which would not have been easy to find without thorough 
code inspection (or, if someone would have run into them).

>For example, consider a list that is pointed to by a global variable
>and some fairly standard way of dealing with singly-linked lists in C:
>
>  SCM head;
>
>  void
>  delete_some ()
>  {
>    SCM *node_ptr = &head;
>    if (should_delete (*node_ptr))
>      *node_ptr = SCM_CDR (*node_ptr);
>    else
>      node_ptr = SCM_CDRLOC (*node_ptr);
>  }
>
Such code should be avoided. Otherwise I think it is difficult to move 
to generational garbage collection: Generational garbage collection is 
based on the assumption, that newer objects only can point to older 
objects. This is true, as long as you don't modifiy existing objects. 
Therefore, write accesses to existing objects must pass through a write 
barrier, which is some code that helps the gc to work correctly even in 
case of references from old to new.

By modifying SCM values through SCM pointers you skip the write barrier. 
When switching to generational GC, such code would have to be fixed, 
either to avoid using the pointer access, or to add some operations that 
perform, what the write barrier would have done. Thus, in order to keep 
the number of places small which require such fixing later, I try to 
avoid using SCM_CDRLOC etc.

Best regards,
Dirk Herrmann



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