guile-devel
[Top][All Lists]
Advanced

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

Re: errors during GC


From: Dirk Herrmann
Subject: Re: errors during GC
Date: Tue, 25 Sep 2001 00:42:38 +0200 (MEST)

On 16 Sep 2001, Michael Livshin wrote:

> Michael Livshin <address@hidden> writes:
> 
> with movement to cards, we now have a freed bit in the lowest byte of
> the first word of objects with tc7 tags.  what should we do with this
> bit?  the nicest thing would be to allow more tc7 tags.  then it would
> also be nice to rename tc7 to tc8, right?

(ISTR that Mikael had some idea of extending the type space for goops.  
However, since I don't know what his concept was, I thought I suggest
something else, which may or may not be conflicting with his ideas.)

What about a general reorganization of the tc7 tags (maybe renaming them
to tc8 in this pass?).  IMO, even if the comment behind scm_tc7_smob in
tags.h indicates differently, it should in the meantime be possible to
change all tc7 tags without problems - there is only one exception, namely
scm_tc7_vector and scm_tc7_wvector, which have to have a certain
relationship.

What goals should a reorganization have?  Well, I think it might be
usefull to use a general ordering scheme for related types.  For example,
we have a set of tc7 codes which all fullfill the procedure? predicate.  
Since these are spread around the tc7 number space somewhat randomly,
there is no SCM_PROCEDUREP macro - you have to call scm_procedure_p.  IMO
it would be nice to have common types share a common bit pattern in the
low level bits.  For example, x0001101 could represent vectors and weak
vectors, instead of 000011x1.  For the set of procedure types, it would be
nice to have them share a pattern like xxxx0101 or whatever, thus allowing
for 16 different procedure types.  Currently, there seem to be 13, plus
applicable smobs, plus applicable structs and objects.

IMO, such a scheme might be less confusing than what we have now.

Best regards
Dirk Herrmann




reply via email to

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