Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!steinmetz!sunray!oconnor From: oconnor@sunray.steinmetz (Dennis Oconnor) Newsgroups: comp.sys.amiga Subject: Re: RISC (was Re: Atari Transputers ? & A British ST/Amiga Rival ?) Message-ID: <7635@steinmetz.steinmetz.UUCP> Date: Thu, 15-Oct-87 09:15:47 EDT Article-I.D.: steinmet.7635 Posted: Thu Oct 15 09:15:47 1987 Date-Received: Sat, 17-Oct-87 09:09:14 EDT References: <21258@ucbvax.BERKELEY.EDU> <2494@cbmvax.UUCP> Sender: root@steinmetz.steinmetz.UUCP Reply-To: oconnor@sunray.UUCP (Dennis Oconnor) Followup-To: comp.sys.arch Organization: General Electric CRD, Schenectady, NY Lines: 65 ( text in square-brackets [...] is mine. DMOC ) In article <2494@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >On the other hand, folks are building RISC machines to be 1 cycle machines, >not 3 cycle machines. So now you're talking about 40ns [at 25MHz] memory cycle >times if you really want to be as fast as possible. Which you need to be, >since that's the big (main, only, whatever) advantage of RISC over CISC. Basicly correct, but not entirely. RISCs indeed need about 1.5(+-.3) memory accesses per cycle ( 1 for instructions, .2-.8 for operands ). However, this does not directly lead to a need for RAM that has an access time lower than the cycle time. Naturally you can seperate your instruction and data memory, and then you can pipeline the memory, and then you can use wide memories, and then you can use interleaved banks of memory, and then you can use look-ahead systems... It's best to design these features in from the start, they are horrendous to add in later ( some of them ), and they usually raise latency and complicate the hardware ( no free lunch ), but they do allow the processor to run using slower-than-cycle-time memories without taking a major (or even proportionate) performance hit, even when the slower-memory is the cache. A better name for "RISC" might be "BFMI" : _B_ig _F_ast _M_emory that's _I_nexpensive. ( BFMI also stands for "Brute Force and Massive Ignorance" ). Well, when you've got dynamite you don't dig ditches with a scalpel. >So now my RAM cache is ECL, or maybe GaAs. Or maybe too slow for the CPU. For 40ns? Please, get up to date. 35ns CMOS static RAMS have been around for years, in 64K and bigger. Check out Performance, Cypress, and IDT : the state-of-the-art in production (like, delivery NOW ) CMOS static rams is 15ns, 16k by 4. I've eye-balled them, they exist. Someone I know has tested some older 16kx4 CMOS RAMS: 12ns access time. >... shs@ji.Berkeley.EDU (Steve Schoettler) says: >> What we really need is an on-chip cache with process-id-tags so context >> switching doesn't destroy the cache completely (68020 has to flush its >>cache with every context switch). > >If you could keep the overhead of managing the id-tags below that of flushing >the cache, sure. I'll use any little tweak you can give me. The Stanford MIPS processor has a neat scheme they call APHID ( for Active Process Header ID ) : replace some number of the MSb's of all the addresses generated with a number unique to each process. Each process thinks it is accessing memory locations 0..2**n-1, when really each process accesses (k*2**n)+(0..2**n-1). Low overhead, allows relocation of processes easily. Kinda grainy ( every process is allocated some power-of-two sized block of memory, which may waste 49% of memory ) but cheap to implement, gate-wise. Solves the cache-purge problem nicely. Also gives some protection of processes and resources from bad processes, and provides some fault-detection ( array-out-of-bounds kinda stuff ) capability. >> Steve Schoettler, humble CS researcher. >-- >Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh > "The B2000 Guy" PLINK : D-DAVE H BIX : hazy Sure, hey, but comp.sys.arch is the correct place for this discussion. In fact, they probably already had it. -- Dennis O'Connor oconnor@sungoddess.steinmetz.UUCP ?? ARPA: OCONNORDM@ge-crd.arpa "If I have an "s" in my name, am I a PHIL-OSS-IF-FER?"