Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: machines with some loadable microcode are easier to fix
Keywords: microcode hardware bugs
Message-ID: <44507@mips.mips.COM>
Date: 4 Jan 91 18:49:41 GMT
References: <71537@bu.edu.bu.edu> <1991Jan04.035359.12547@kithrup.COM>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 43

In article <1991Jan04.035359.12547@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes:

>John Mashey once posted that simulating a MIPS R3000 (I think it was),
>completely in software, from power up to single user mode, took something
>like seven days.  (John, sorry if I've gotten something wrong.)
Close.  This is a gate-level-simulator for a next-generation million-transistor
chip (R4000) + surrounding hardware environment, NOT the 100K transistor
R3000.  It takes 8 days on a 50-vmips RC6280.  I'm told that "ls"
on an empty directory takes a morning...

Note that the general discussion of micro-code machines seems to have mixed
up a lot of issues.
	1) As somebody noted, the IBM S/360 line used microcode for a bunch of
	architectural reasons, having little to do with bug-fixing.
	2) Appropriate architectures and their implementations change over
	time in response to fundamental underlying technology trends in
	both hardware and software.  What was appropriate in an era of
	expensive core memory and CPUs consructed from many parts may
	be rather irrelevant in an era of VLSI processors, cheap DRAM,
	and fast small SRAMs.
	See Hennessy&Patterson, p. 208-243.  particularly relevant is:
	"The drawback of microcode has always been performance.  This is because	microprogramming is a slave to memory technology.: The clock cycle
	time is limited by the time to read microinstructions from control
	store.  In the 1950s, microprogramming weas impractical since
	virtually the oinly technology available for control store was the
	same one used for main memory.  In the late 1960s and early 1970s,
	semiconductor memory was available for control store, while main memory
	was constructed from core.  The factor of ten in cycle time that
	differentiated the two technologies opened the door for microcode.
	The popularity of cache memories in the 1970s again closed the gap,
	and machines were again built with the same technology for control
	store and memory.
	For these reasons instruction sets invented since 1985 have not relied
	on microcode.  Though no one linkes to predict the future-least of all
	in writing-it is the authors' opinion that microprogramming is bound to
	memory technology.  if in some future technology ROM becomes much
	faster than RAM, or if caches are no longer effective, microcode
	may regain its popularity."
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086