Newsgroups: comp.arch,comp.lang.lisp,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!trib.apple.com!amd!amdahl!netcomsv!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: Tag bits in data
Message-ID: <hbakerCw559q.5oy@netcom.com>
Organization: nil
References: <thinmanCw4w1G.L14@netcom.com>
Date: Wed, 14 Sep 1994 22:32:14 GMT
Lines: 24
Xref: glinda.oz.cs.cmu.edu comp.arch:52944 comp.lang.lisp:14677 comp.lang.scheme:9780

In article <thinmanCw4w1G.L14@netcom.com> thinman@netcom.com (Technically Sweet) writes:
>Why do tag bits have to be in the datum itself?
>Why can't they be stored in the container (cons cells & vectors)
>which point at the datum?  Is this an overhead issue?
>Is it easier to fiddle with the tag in a register than
>to check the pointer-to datum?

You seem to be arguing for tag bits in the memory, but not in the registers.
Not such a bad idea, but the problem is that at some point you've got to
dispatch on the data type.  In most cases, you'd like to think of registers
as a kind of compiler-managed cache, and having to then worry about keeping
separate track of the datatype seems to be a big problem with your scheme.

An alternative is to store tag bits along with the _pointer_ to the
data.  This is a _very_ good idea, because many dispatches can be done
without accessing the data at all.  One minor problem: the 'type' of a
datum can't easily be changed at run-time -- e.g., Smalltalk 'become:'
operation.  For some reason, the persistent OO people really like
dynamically changing datatypes, although I have yet to be convinced
that this is a good idea.

The 'BIBOP' (big bag of pages) scheme is essentially a 'typed pointer'
scheme, because each page has objects of only one type.

