ramsdell@linus.UUCP (John D. Ramsdell) (04/25/88)
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.
altman@mips.csc.ti.com (Arthur Altman) (04/27/88)
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