|SPARC tagged data firstname.lastname@example.org (1991-04-29)|
|Re: SPARC tagged data email@example.com (Eric Benson) (1991-04-30)|
|Re: SPARC tagged data firstname.lastname@example.org (1991-04-30)|
|Re: SPARC tagged data weitek!weaver@Sun.COM (1991-04-30)|
|Re: SPARC tagged data email@example.com (1991-05-07)|
|Re: SPARC tagged data firstname.lastname@example.org (1991-05-08)|
|Re: SPARC tagged data email@example.com (1991-05-09)|
|Re: SPARC tagged data firstname.lastname@example.org (1991-05-10)|
|From:||weitek!weaver@Sun.COM (Michael Weaver)|
|Organization:||WEITEK, Sunnyvale CA|
|Date:||Tue, 30 Apr 91 15:53:58 GMT|
In article <9104291542.AA11213@flora.techfak.uni-bielefeld.de> email@example.com writes:
>Does anyone know what TAGGED DATA instructions are useful for and how to
>use them? ...
Tagged data instructions apparently were borrowed from the Berkeley SOAR
(Smalltalk on a RISC) project. Studies have shown that much of the time in
used by Smalltalk programs is taken up in adds and subtracts, even though
for most adds and subtracts both operands are integers, because in
practice for every add (etc.) a method lookup must be done. That is, the
type of the both operands must be checked, and then a piece of code that
will perform the operation on this combination of operand types must be
found and invoked.
Tagged instructions can be used (on SPARC) by generating instructions as
though all these adds and subtracts were on integers, but using the tagged
add (etc.) instruction rather than add.
Integers are encoded by setting the two low-order bits of a word to zero
to indicate an integer, and the upper 30 to represent the value. Data
types other than integers must have at least one of the two lowest bits
set, and the upper 30 bits can be encoded arbitrarily, so that the 32 bits
can be used (by software) to determine the type and value of the operand.
If two such integers are added with a tagged add, the result is the sum,
similarly encoded. However, if either of the operands of a tagged add has
either of its low bits set, then a trap is taken. The trap handler then
can check both operands, dispatch to appropriate code to effect the add,
and then resume execution following the add.
The overall effect is that adds of integers happen quickly while adds of
other types are slowed down a bit. If most of the adds are actually
integers, the overall run times are improved. I imagine that Lisp can
benefit from these instructions similarly.
See Bush et. al. 'Compiling Smalltalk-80 to a RISC', in Proceedings Second
International Conference on Architectural Support for Programing Languages
and Operating Systems (ASPLOS II).
Return to the
Search the comp.compilers archives again.