Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!think!bloom-beacon!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!k.gp.cs.cmu.edu!lindsay
From: lindsay@k.gp.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: m88000 benchmarks
Keywords: FFT, m88000, benchmark, VLSI System Design
Message-ID: <1986@pt.cs.cmu.edu>
Date: 17 Jun 88 21:09:22 GMT
References: <1941@pt.cs.cmu.edu> <3208@ubc-cs.UUCP>
Sender: netnews@pt.cs.cmu.edu
Organization: Carnegie-Mellon University, CS/RI
Lines: 38

In article <3208@ubc-cs.UUCP> pajari@grads.cs.ubc.ca (George Pajari) writes:
>When pressed at a local presentation on the M88000, Motorola reps conceded
>that the 'infamous' FFT benchmark represented carefuly crafted HAND-CODED
>RISC instructions ordered to take maximal advantage of the pipelining in
>the 88100.  Furthermore, they admitted that the best code by any compiler
>resulted in a 54 cycle loop...ALMOST TWICE THE LENGTH OF THE BENCHMARK CODE.

The article says that the code was "compiled with the scheduler algorithm
(release 1.0)". They also say that the same code, executed without
overlaps, requires 53 clocks. 

If your rep is correct, then it's likely that the article was submitted for
publication some months ago. The authors were probably just optimistic
about how quickly everything would come together.

Writing a "code scheduler" for a compiler is an interesting task. The 88000
has several nice properties in this regard; only branches have data
dependent timing; and only load/store can take cache hits.  Plus,
imperfections in the scheduling algorithm don't lead to incorrect code.
(The scoreboard insures that you don't e.g. read a register before incoming
data has arrived in it.)

Viewed from a distance, an 88000 scheduler looks quite simple: the "machine
model" isn't too complex, and the interface (machine code in, machine code
out) is straightforward. Viewed close up, I'm sure that the implementers
have hit some kind of grief: a problem with register lifetimes and live
sets: or, problems with labels and directives: or just suboptimal results
on the biggest customer's favorite benchmark. Or, more likely, everybody
was too busy fixing bugs in some other component.

I'd like to hear from Tadpole Technology about what they did that gave such
a goose to the Dhrystone figures.


-- 
Don		lindsay@k.gp.cs.cmu.edu    CMU Computer Science

"Imitation is not the sincerest form of flattery. Payments are."
- a British artist who died penniless before copyright law.