Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!sri-spam!mordor!lll-lcc!ames!oliveb!intelca!mipos3!cpocd2!howard
From: howard@cpocd2.UUCP (Howard A. Landman)
Newsgroups: comp.arch
Subject: Re: What should be in hardware but isn'
Message-ID: <915@cpocd2.UUCP>
Date: Fri, 16-Oct-87 13:36:10 EDT
Article-I.D.: cpocd2.915
Posted: Fri Oct 16 13:36:10 1987
Date-Received: Wed, 21-Oct-87 20:29:04 EDT
References: <581@l.cc.purdue.edu> <43700027@uicsrd>
Reply-To: howard@cpocd2.UUCP (Howard A. Landman)
Organization: Intel Corp. ASIC Systems Organization, Chandler AZ
Lines: 46

>> Written  9:22 pm  Sep 28, 1987 by stachour@umn-cs.UUCP in comp.arch
>> I've NEVER seen anyone design compilers for a machine that is only
>> being similated, and chose the architecture of the hardware based
>> on measurement, and build the machine later. (Well, one exception,
>> Multics many years ago, but that design set goals seldom met now.)

In article <43700027@uicsrd> turner@uicsrd.csrd.uiuc.edu writes:
>Here at CSRD we have been designing compilers for Cedar since BEFORE
>the machine was ever simulated.  I think that compiler design is
>obviously important enough to be done concurrently with architecture
>evaluation, anyone else feel differently??

No, I agree.  When we were designing the RISC I at Berkeley a while back,
we had a compiler and an instruction-level simulator long before the design
finalized.  We also could run lower level simulations (eventually, right down
to switch simulation of the transistor netlist extracted from the chip layout)
at the same time and compare them with the high-level simulation.  This was
used to test out the design as it progressed.  Finally, the coding for the
control PLA of the chip was generated automatically from the instruction-set
level description used for high level simulation.  Thus it was not only
possible, but routine, for us to change the instruction set, "push a button",
and have a new control PLA generated, dropped into the chip layout, the new
chip layout extracted, 3 levels of simulation run and results compared, all
in under 24 hours with no human intervention.  This was done about 30 times
in the last 45 days of the design process.  The final "tweak" to the
architecture was done 1 day before we sent out the database for maskmaking!

The switch level simulator was never run for more than about 100 instruction
cycles, because of CPU limitations, but the high-level simulator had many
complete programs run on it.

Only one minor functional bug, affecting the condition codes after a certain
instruction, got past all this into the final chip.  Rather than declare it
a "feature", we modified the assembler to insert an additional instruction
where needed to assure that the condition code was correct.  This had an
insignificant effect on the performance of the machine.

While the design wasn't based on measurements taken from the compiler before
design began, it *was* based on many, many measurements of the performance
of VAXes, and was modified as compiler results became available.

-- 
	Howard A. Landman
	{oliveb,hplabs}!intelca!mipos3!cpocd2!howard	<- works
	howard%cpocd2%sc.intel.com@RELAY.CS.NET		<- recently flaky
	"Unpick a ninny - recall Mecham"