Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!linus!ramsdell
From: ramsdell@linus.UUCP (John D. Ramsdell)
Newsgroups: comp.arch
Subject: Missing SPARC instruction?
Message-ID: <30185@linus.UUCP>
Date: 25 Apr 88 16:15:31 GMT
Reply-To: ramsdell@darwin.UUCP (John D. Ramsdell)
Organization: The MITRE Corporation, Bedford MA
Lines: 39
Keywords: SPARC, Lisp

Two very common commands executed by a Lisp implementations is tagged
addition and accessing an element of a pair (a CONS cell).  The SPARC
architecture defines two instructions for tagged addition.

	taddcc		| Sets overflow condition on bad tag.
	taddcctv	| Sets overflow and traps on bad tag.

Assuming the tag for a pair is 3, one possible way of getting the
first element of a pair in %g3 to %g4 is:

	ld %g3-3, %g4	| Traps with mem_address_not_aligned on bad tag.

Noticeably absent is a load instruction that simply sets the overflow
condition code on bad tag.  Assuming such an instruction is called
ldcc, bad tags could be handled as follows:

	ldcc %g3-3, %g4	| Sets overflow condition on bad tag.
	bvc,a OK_tag	| Handle bad tag.
	first OK instruction
	ba,a  bad_tag
OK_tag: second OK instruction

Thus, for the cost of one instruction per pointer dereference, one
could avoid the cost of trapping on bad tags.

Two questions:

1) Is there some reason to believe traps will be handled quickly, and
if so, why have taddcc?

2) Assuming a Lisp implementor has decided to avoid trapping, is there
evidence that taddcc is more important than ldcc, so much so as to
justify that ldcc not be implemented?

John

PS.  I received Intel's 80960KB Programmer's Reference Manual, and
noted that it made no claim that the 80960KB was a RISC architecture.
Maybe the authors know something the sales people don't.