Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsl!wkk
From: wkk@cbnewsl.att.com (wesley.k.kaplow)
Newsgroups: comp.arch
Subject: AT&T CRISP Processor
Message-ID: <1990Nov14.213558.4176@cbnewsl.att.com>
Date: 14 Nov 90 21:35:58 GMT
Organization: AT&T Bell Laboratories
Lines: 30

The AT&T CRISP Processor is not used in the 5ESS switch.  My department
designed an interface board that uses the CRISP processor as a controller
and data reduction engine.  At one time there was a lot of internal
research projects that used the CRISP, but I beleive that CRISP per se
is not longer available, but that a follow on chip was produced for
another computer company for incorporation into their products.

My direct experiences with CRISP, as I ponder over an old CRISP requirements
document, was that with 0-wait state memory, and an early release of
an optimizing compiler, the chip take 1.5-2.0 cycles per instruction,
a number that could, and was probably improved in any new version.
Also, since the OP-Codes were developed by taking the most comonly used
instructions and coding them into 16-bits, CRISP gets great code desnsity.
I remember comparing R3000 code vs. CRISP and seeing about a 50% code
size difference, favoring CRISP.


Programing using a Stack Cache, which is what the CRISP uses, takes a little
getting used to, but just like anything else you get used to it.  CRISP's
branch prediction is also an interesting feature with instructions like
"ifFjmpy ADDRESS" which means: predict a jump to ADDRESS, i.e., hopefully
the condition will be false.

Well, thats all for now, 

Wesley Kaplow
AT&T Bell Labs.
Whippany, NJ 07981

att!wayback!wkk