There was an interesting discussion in the "fonc" list a short time ago
about trying to make the system as independent as possible from the
representation of "tags".
I suppose that all of you know that objects in dynamically typed
languages are tagged so that the system can know the type of each one at
run time. There are several ways of doing this. A simple solution is to
have the first word in each object point to some other object (a class,
for example) which indicates that type. Another solution is to divide up
the memory space into regions and only allow objects of a given type in
each region. A variation of this is to reserve some bits in the object
pointer to indicate the type. In practice a combination of these is
almost always used.
For Squeak, for example, there are three systems. The first is using the
lowest bit in the object reference to separate small integers (1) from
all other objects (0). The second, which applies to the "all other
objects" case, uses some bits in a header word as an index into a table
which then points to the class. In the third option the header includes
a full extra word which is a direct pointer to the class.
This method works well because objects are aligned on multiple of four
bytes, so all normal pointers have the lowest two bits as 00 and can
never be confused with small integers. The problem is that if you add
two integers then the result will be wrong: you have to clear the tags,
do the addition and then set the tag (just clearing one of the tags has
the same effect for addition). Note that we lost one bit of precision
for small integers, but pointers are no worse off due to this scheme (we
can still address 4GB).
For Self the two lowest bits are 00 for small integers (so we lose two
bits), 01 for object pointers, 10 for floating point and 11 for header
words. This would seem to make access to an object's fields more costly,
but in practice most of the time you have a constant offset (or an index
register plus a constant) added to a base address and can adjust the
constant so no extra operations are needed. The small integers can now
be added and subtracted very simply and you just have to watch out for
overflow. The floating point numbers got the short end of the stick with
a serious loss in precision, but you get better performance than the
"boxed" (full objects rather than encoded in object references) floats
like in Self. And you can have boxed doubles if needed. The special tags
for headers allow you to scan though memory at very high speeds until
you find some reference you want and then back up a little to see what
object it is in. Without this you have to scan by objects (which
normally implies recursion and other complications) to get the same
result.
For RISC42 I changed the object reference format a while back so that
the top two bits are 00 for positive small integers, 11 for negative
small integers and 01 or 10 for object references (two sizes of
task/object division). Note that the precision of small integers is 31
bits like in Squeak. With this format not only do 32 bit addition and
subtraction instructions work just fine, but also signed multiplication
and division, shifts and logical operations too. Only rotation
instructions don't work. Of course, the result won't be a valid small
integer for all inputs. One solution would be to add a second overflow
flag to detect this. Another would be to redefine the old overflow flag,
but in some cases we would like the old definition.
The interesting thing about this scheme is how different the costs are
for a software versus hardware implementation. It is a bit complicated
to check these flags in software (you need a shift, an exclusive or and
a masking operation) and detecting non small integer results is much
worse. For the hardware a single exclusive or gate will to the job and
detecting overflow adds only a little more logic.
So a system that has both a hardware and software-only implementations
would be improved by allowing different tagging schemes. This would make
sharing images more complicated (but not that much).
-- Jecel
