clc5q@hemlock.cs.Virginia.EDU (Clark L. Coleman) (05/17/91)
The April 29, 1991 EE Times, page 16, mentions a 33-MHz TRON micro
from Fujitsu that supposedly runs at 32 MIPS. No benchmark explanation.
It is not intended for workstations, so we will probably never see
SPEC results for it, and it won't be sold in the U.S. But I am curious
to find out if anyone knows anything about the chip and the extremely
high ratio of 32 MIPS to 33 MHz for a CISC chip. It has an on-chip cache
of 2 KB and is described as "a five-pipeline CISC processor" that is
"capable of multitasking", "32-bits", and "developed to run the TRON
operating system or Unix."
Clever design or another meaningless "MIPS" claim?
-----------------------------------------------------------------------------
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence." E.W.Dijkstra, 18th June 1975.
||| clc5q@virginia.edu (Clark L. Coleman)yuhara@kiko.stars.flab.fujitsu.co.jp (Masanobu Yuhara) (05/20/91)
$@"((JIn <1991May16.182143.15390@murdoch.acc.Virginia.EDU> clc5q@hemlock.cs.Virginia.EDU (Clark L. Coleman) said: Clark> The April 29, 1991 EE Times, page 16, mentions a 33-MHz TRON micro Clark> from Fujitsu that supposedly runs at 32 MIPS. No benchmark explanation. Clark> It is not intended for workstations, so we will probably never see Clark> SPEC results for it, and it won't be sold in the U.S. But I am curious Clark> to find out if anyone knows anything about the chip and the extremely Clark> high ratio of 32 MIPS to 33 MHz for a CISC chip. It has an on-chip cache Clark> of 2 KB and is described as "a five-pipeline CISC processor" that is Clark> "capable of multitasking", "32-bits", and "developed to run the TRON Clark> operating system or Unix." The 33-MHz Gmicro/300 runs 57,625 Dhrystones/sec, if I remember correctly. I guess its Dhrystone version is 1.1. If you define one dhry-MIPS to be 1757 (as IBM does), you get 32.8 MIPS. SPEC results are not available. TRON instruction set is very CISCy, but this chip was designed RISCy. i.e. most primitive instructions run in one cycle (if cache hits) including: add @(offset:32,R1), R2 ; R2 += memory(R1 + 32_bit_offset) One more comment: it has a 2KB data cache as well as a 2KB instruction cache. ------ yuhara@flab.fujitsu.co.jp Masanobu Yuhara Distributed Processing Section, Optical Networking Systems Laboratory, Optical Interconnection Division, Fujitsu Laboratories Ltd.
sakurai@gmd.ed.fujitsu.co.jp (SAKURAI atsushi) (05/21/91)
In article <YUHARA.91May20200857@kiko.stars.flab.fujitsu.co.jp> yuhara@kiko.stars.flab.fujitsu.co.jp (Masanobu Yuhara) writes: > > $B"((JIn <1991May16.182143.15390@murdoch.acc.Virginia.EDU> > clc5q@hemlock.cs.Virginia.EDU (Clark L. Coleman) said: > >Clark> The April 29, 1991 EE Times, page 16, mentions a 33-MHz TRON micro >Clark> from Fujitsu that supposedly runs at 32 MIPS. No benchmark explanation. >Clark> It is not intended for workstations, so we will probably never see It is for workstations, too:-) Unix is now running on the Gmicro/300 chip. >Clark> SPEC results for it, and it won't be sold in the U.S. But I am curious >Clark> to find out if anyone knows anything about the chip and the extremely >Clark> high ratio of 32 MIPS to 33 MHz for a CISC chip. > >The 33-MHz Gmicro/300 runs 57,625 Dhrystones/sec, if I remember correctly. >I guess its Dhrystone version is 1.1. Right, but >If you define one dhry-MIPS to be 1757 (as IBM does), you get 32.8 MIPS. Slitly different. The number 32 MIPS comes from 57,625 / 1800, otherwise you would get 33 MIPS. Originally, in article <1991May16.182143.15390@murdoch.acc.Virginia.EDU> clc5q@hemlock.cs.Virginia.EDU (Clark L. Coleman) writes: >Clever design or another meaningless "MIPS" claim? I think things are HALF/HALF. Thanks to its one-cycle-pipeline and Harvard-style cache organization, the Gmicro/300 executes even a complex instruction somewhat fast as Yuhara said. On the other hand, it never runs 32 Millions of Instructions Per Second literally. For 32 MIPS only means 32 VAX-MIPS, I would rather say it is not a Millions of Instructions Per Second but another Meaningless Instructions Per Second. So, you'd better wait the SPEC marks which will be announced by the maker. -- SAKURAI atsushi E-mail: sakurai@gmd.ed.fujitsu.co.jp
sakurai@gmd.ed.fujitsu.co.jp (SAKURAI atsushi) (05/21/91)
In article <YUHARA.91May20200857@kiko.stars.flab.fujitsu.co.jp> yuhara@kiko.stars.flab.fujitsu.co.jp (Masanobu Yuhara) writes: > > $B"((JIn <1991May16.182143.15390@murdoch.acc.Virginia.EDU> ^^ Oops. JIS code. > clc5q@hemlock.cs.Virginia.EDU (Clark L. Coleman) said: > >Clark> The April 29, 1991 EE Times, page 16, mentions a 33-MHz TRON micro >Clark> from Fujitsu that supposedly runs at 32 MIPS. No benchmark explanation. >Clark> It is not intended for workstations, so we will probably never see It is for workstations, too:-) Unix is now running on the Gmicro/300 chip. >Clark> SPEC results for it, and it won't be sold in the U.S. But I am curious >Clark> to find out if anyone knows anything about the chip and the extremely >Clark> high ratio of 32 MIPS to 33 MHz for a CISC chip. > >The 33-MHz Gmicro/300 runs 57,625 Dhrystones/sec, if I remember correctly. >I guess its Dhrystone version is 1.1. Right, but >If you define one dhry-MIPS to be 1757 (as IBM does), you get 32.8 MIPS. Slitly different. The number 32 MIPS comes from 57,625 / 1800, otherwise you would get 33 MIPS. Originally, in article <1991May16.182143.15390@murdoch.acc.Virginia.EDU> clc5q@hemlock.cs.Virginia.EDU (Clark L. Coleman) writes: >Clever design or another meaningless "MIPS" claim? I think things are HALF/HALF. Thanks to its one-cycle-pipeline and Harvard-style cache organization, the Gmicro/300 executes even a complex instruction somewhat fast as Yuhara said. On the other hand, it never runs 32 Millions of Instructions Per Second literally. For 32 MIPS only means 32 VAX-MIPS, I would rather say it is not a Millions of Instructions Per Second but another Meaningless Instructions Per Second. So, you'd better wait the SPEC marks which will be announced by the maker. -- SAKURAI atsushi / FUJITSU LIMITED E-mail: sakurai@gmd.ed.fujitsu.co.jp
rodman@sgi.com (Paul K. Rodman) (05/24/91)
In article <YUHARA.91May20200857@kiko.stars.flab.fujitsu.co.jp> yuhara@kiko.stars.flab.fujitsu.co.jp (Masanobu Yuhara) writes: > >TRON instruction set is very CISCy, but this chip was designed RISCy. >i.e. most primitive instructions run in one cycle (if cache hits) including: > add @(offset:32,R1), R2 ; R2 += memory(R1 + 32_bit_offset) > I worked on high-end CISC machines a decade ago that could even do: reg += memory(reg + reg + offset) in one cycle. (assuming cache hits) This is called "designing a high-end machine that isn't worthless", not RISCy design, IMHO....:-) -- Paul K. Rodman Advanced Systems Division rodman@sgi.com Silicon Graphics, Inc. KA1ZA Mountain View, Ca.