🚀 go-pugleaf

Does anybody out there have any Dhrystone or Whetstone numbers for
the i860?  If not, why not?

Intel... are you out there?  I'm calling your bluff.

I see where Intel has gotten a lot of publicity from their claim of
80 Mflops "peak" (single precision) and 60 Mflop "peak" (double
precision).  Well, I've finally had a chance to look over the
instruction set, and it is bloody obvious that it is going to take
the compiler writers a LONG LONG TIME before they can get normal
applications to compile down to code that will even approach 2/3
of these "peak" figures.  The problem of filling branch delay slots
shouldn't be too hard (and this is an old and previously solved
problem anyway), but to fully exploit the floating-point pipeline,
the double-wide instruction mode, and the floating-point multiply
and add/subtract instructions, not to mention taking account of
all of the dozen or so weird one-cycle (in some cases multi-cycle)
freeze conditions, presents a new and very difficult set of
code optimization problems.

Now considering the fact that Intel is claiming that they have
(1) a C compiler, (2) a FORTRAN compiler, (3) an assembler,
(4) a linker, (5) a simulator, (6) a (symbolic?) debugger,
and (last but not least) UNIX, all available for this chip,
it seems to me that somewhere along the way (you would think that)
they would have run both Dhrystone and Whetstone benchmarks.
Right?

So why don't those numbers appear on the first page of the
"data sheet" along side the (blatantly misleading) "peak" Mflop
numbers?  Who is Intel trying to kid?  Does anybody out there
who actually makes design-in decisions still (in this day and age)
fall for this s**t of quoting MIPS and Mflops?  If so, then it is
a sad comment on the business as a whole, and on hardware engineers
in particular.

One last question.  Considering all of the i860's (complicated)
parallelism would *could* be productively used, I'd like to know
in Intel (or anybody else) is building (or has built, or is planning
to build) some software tool which can gobble up mediocre code and
re-mangle it into execelent code.

Motorola has a tool like this for the 80000 (all it has to do is to
try to fill branch delay slots because the 88000 is both simpler and
less "parallel").  Unfortunately, I have heard that early versions
were fairly buggy.

-- 
// Ron Guilmette  -  MCC  -  Experimental Systems Kit Project
// 3500 West Balcones Center Drive,  Austin, TX  78759  -  (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg