Newsgroups: comp.arch,comp.lang.lisp,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!fs7.ece.cmu.edu!europa.eng.gtefsd.com!gatech!cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!gw1.att.com!nntpa!nntpa.cb.att.com!lgm
From: lgm@polaris.ih.att.com (Lawrence G. Mayka)
Subject: Re: Tag bits in data
In-Reply-To: barmar@nic.near.net's message of 14 Sep 1994 18:36:52 -0400
Message-ID: <LGM.94Sep18152318@polaris.ih.att.com>
Sender: news@nntpa.cb.att.com (Netnews Administration)
Nntp-Posting-Host: polaris.ih.att.com
Organization: AT&T Bell Laboratories, Naperville, Illinois, USA
References: <thinmanCw4w1G.L14@netcom.com> <357tu5$nrp@nic.near.net>
Date: Sun, 18 Sep 1994 20:23:18 GMT
Lines: 39
Xref: glinda.oz.cs.cmu.edu comp.arch:53043 comp.lang.lisp:14718 comp.lang.scheme:9798

In article <357tu5$nrp@nic.near.net> barmar@nic.near.net (Barry Margolin) writes:

   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?

   That *is* where most implementations put the tags.  A reference to an
   object is normally <tag, address>.  In the case of BIBOP implementations,
   the tag is implicit in the address.  In the case of immediate data
   (fixnums, usually) the reference *is* the object, and the above tuple
   becomes <tag, data>; but since this is immediate data, it is still stored
   in the container as you suggested.

This typically applies to "gross" tagging--e.g., the distinguishing of
perhaps 8 "major" datatypes.

   Some implementations put some kind of type information in the object itself
   as well.  This is useful for some GC implementations that scan memory
   linearly and need to know where objects begin and end, and where they
   contain references.

If one defines tags to include any sort of dynamic type information,
it becomes more obvious why tags must often reside in the object
itself rather than the references to it: User type definition (via
DEFCLASS or DEFSTRUCT) makes the number of types almost limitless.  An
a priori setaside of 16 bits, for example, to allow for the definition
of up to 65K classes would be a considerable waste of space and time
for those applications that used less than 50 classes.

In addition, as someone pointed out, types of metaclass STANDARD-CLASS
must support the CHANGE-CLASS, UPDATE-INSTANCE-FOR-DIFFERENT-CLASS,
and UPDATE-INSTANCE-FOR-REDEFINED-CLASS protocols.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@ieain.att.com

Standard disclaimer.
