From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: Re: The relationship between SCM and scm_t_bits. Date: Sat, 15 May 2004 09:31:52 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <40A5C768.5030603@dirk-herrmanns-seiten.de> References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1084604858 11436 80.91.224.253 (15 May 2004 07:07:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 15 May 2004 07:07:38 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat May 15 09:07:26 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOtGX-0000lg-00 for ; Sat, 15 May 2004 09:07:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOtFR-0002K9-Em for guile-devel@m.gmane.org; Sat, 15 May 2004 03:06:17 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BOtF1-0002Gn-Ec for guile-devel@gnu.org; Sat, 15 May 2004 03:05:51 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BOtEU-0001xT-Pa for guile-devel@gnu.org; Sat, 15 May 2004 03:05:49 -0400 Original-Received: from [212.227.126.185] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOtEU-0001xL-Ah for guile-devel@gnu.org; Sat, 15 May 2004 03:05:18 -0400 Original-Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BOtES-0004x4-00; Sat, 15 May 2004 09:05:16 +0200 Original-Received: from [80.131.49.51] (helo=dirk-herrmanns-seiten.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BOtES-00063e-00; Sat, 15 May 2004 09:05:16 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040220 X-Accept-Language: de, en Original-To: Marius Vollmer In-Reply-To: X-Enigmail-Version: 0.76.8.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:494e3e4d1bf8dc247959c49e6f1f4215 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3713 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3713 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