Related articles |
---|
SPARC tagged data horst@techfak.uni-bielefeld.de (1991-04-29) |
Re: SPARC tagged data eb%watergate@lucid.com (Eric Benson) (1991-04-30) |
Re: SPARC tagged data moss@cs.umass.edu (1991-04-30) |
Re: SPARC tagged data weitek!weaver@Sun.COM (1991-04-30) |
Re: SPARC tagged data kers@otter.hpl.hp.com (1991-05-07) |
Re: SPARC tagged data pardo@june.cs.washington.edu (1991-05-08) |
Re: SPARC tagged data henry@zoo.toronto.edu (1991-05-09) |
Re: SPARC tagged data pardo@june.cs.washington.edu (1991-05-10) |
Newsgroups: | comp.compilers,comp.arch |
From: | moss@cs.umass.edu (Eliot Moss) |
Followup-To: | comp.compilers |
Keywords: | SPARC, design, architecture |
Organization: | Dept of Comp and Info Sci, Univ of Mass (Amherst) |
References: | <9104291542.AA11213@flora.techfak.uni-bielefeld.de> |
Date: | 30 Apr 91 12:32:34 GMT |
Well, I cannot speak for SPARC and say what the instructions were DESIGNED
for, but as the moderator pointed out, they can be used to good effect in
implementing languages such as Smalltalk and LISP, which used tagging to
distinguish (small, i.e., 30-bit) integers from pointers. One uses a tag of 00
in the low bits for integers, and a tag of 01 (say) for pointers. All offsets
from pointers are scaled by -1 to compensate for the 01 in the low bits. Note
that integer add/sub on pointers will be trapped (if you used the tagged
add/sub instructions) and pointer access off an integer can also be trapped.
This means you don't have to insert gobs of tag checking code all over the
place. Multiply and divide tend to require scaling and adjustment anyway, and
bsides, they take long enough, and are rare enough (compared with add/sub)
that additional penalty in handling the tags is judged "acceptable".
--
J. Eliot B. Moss, Assistant Professor
Department of Computer and Information Science
Lederle Graduate Research Center
University of Massachusetts
Amherst, MA 01003
(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.