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?
--
Lance Norskog
·······@netcom.com
Artisputtingtogether. Art s th ow n aw y.
In article <·················@netcom.com> ·······@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.
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.
--
Barry Margolin
······@near.net
In article <·················@netcom.com> ·······@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.
On Wed, 14 Sep 1994, Henry G. Baker wrote:
> 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.
One important use of become: with a database such as GemStone is to
migrate existing database instances across schema (class) changes.