Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!killer!pollux!ti-csl!mips!altman
From: altman@mips.csc.ti.com (Arthur Altman)
Newsgroups: comp.arch
Subject: Re: Missing SPARC instruction?
Message-ID: <47548@ti-csl.CSNET>
Date: 26 Apr 88 23:07:22 GMT
References: <30185@linus.UUCP>
Sender: news@ti-csl.CSNET
Reply-To: altman@csc.ti.com (Arthur Altman)
Organization: TI Computer Science Center, Dallas
Lines: 62
Keywords: SPARC, Lisp

In article <30185@linus.UUCP> ramsdell@darwin.UUCP (John D. Ramsdell) writes:
>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

If the goal is to speed the common, correct case, and one believes
that the argument to CAR/CDR is most often a CONS cell, your ldcc
suggestion slows down the common, correct case by making it bear the
cost of loading the condition codes and branching.  Since the only
other case is infrequent and an error, it seems pointless to speed
that up.  The single instruction version of CAR/CDR wins on average.

In the case of addition, there are two cases considered by the SPARC
taddcc: the common, correct case where both arguments are fixnums,
and all other cases.  The trouble is that all other cases include
those where both arguments are numbers but not both fixnums, which is
not an error, as well as the error cases where one of the arguments is
not a number.  It would be good if taddcc differentiated these less
frequent but correct cases from the errors.

Hope this helps,

Arthur Altman
Texas Instruments, Inc.
Computer Science Center
Dallas, TX

altman@csc.ti.com









-Arthur

Domain Address:  altman@tilde.csc.ti.com
CSNET: altman@ti-csl
UUCP:  {im4u, infoswx, smu, texsun, rice} ! ti-csl ! altman
U.S. Mail: Texas Instruments, M.S. 238, P.O. Box 655474, Dallas, Tx. 75265