Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: i860 and compilers
Keywords: i860 N10
Message-ID: <4524@pt.cs.cmu.edu>
Date: 20 Mar 89 18:33:24 GMT
Organization: Carnegie-Mellon University, CS/RI
Lines: 31

In all this talk about the Intel 860, there's been very little mention
of compilers.

It seems clear that pipeline mode is beyond the compiler technology
that Intel is bringing to bear. I expect them to ship a library of
handcoded routines, which do dot-product and the like. At some point,
the compilers will acquire directives ( "do a dot product" ) and/or
pattern matching ( "gosh, that looks like code for a dot product" ).
The compiler will then inline the library handcode, with appropriate
parameterization. 

Part of the problem is the (poor) idea of having to catch the hot,
smoking data as it flys out of the pipe.  Self-draining pipelines would
have been easier on both the compilers and the interrupt handling.  The
pipeline mode's startup and shutdown transients, which trash things,
are also undesirable. 

The data-chaining features sound intractable.  Perhaps another
dual-instruction mode would have been better - one instruction to the
FADD unit, the other to FMUL.

The existing dual instruction mode is OK, because compilers can largely
ignore it. A postprocessor (or an optimizing assembler) can do all the
code scheduling. It can do a good job, too, if the compiler emits
enough hints.

Perhaps Intel should have dropped the floating point unit, and put in a
second integer ALU instead.  It would have goosed the Dhrystones, no?

-- 
Don		D.C.Lindsay 	Carnegie Mellon School of Computer Science
--