Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!ima!cfisun!stardent!pc
From: pc@Stardent.COM (Paul Cantrell)
Newsgroups: comp.arch
Subject: Re: Vector processors, i860
Keywords: Vector, array processors, i860.
Message-ID: <1991Feb8.144035.1076@Stardent.COM>
Date: 8 Feb 91 14:40:35 GMT
References: <1991Feb3.061217.21988@watdragon.waterloo.edu> <1991Feb03.082253.12458@kithrup.COM> <1991Feb3.223732.3581@watdragon.waterloo.edu>
Organization: Stardent Computer, Newton MA
Lines: 111

Re:	the discussion about what makes the i860 a difficult chip to use.

I was at Alliant when they were porting their SMP parallel mini-supercomputer
to i860. Although there are a lot of things Intel could have done to make the
chip easier for people to integrate into systems, basically the chip works ok.
I don't think that the problems that Colin has pointed out are really reasons
not to use the chip. And the chip *does* have many qualities which can make it
be a really fine chip for a multiprocessing application.

In article <1991Feb3.223732.3581@watdragon.waterloo.edu> ccplumb@rose.uwaterloo.ca (Colin Plumb) writes:
>Howver, when I said it drops the pipeline on the floor, I meant the
>instruction pipeline, where you are, in fact, provided with enough
>information to reconstruct it's state, but it's not just a PC.
>
>The worst case, as is usual with chips, is taking a page fault, since
>it can occur mid-instruction and you usually want to do a context
>switch while the page is loaded.

Well, the problem occurs whether or not you need to context switch. Colin
is right that it's a lot of trouble to continue from the exception because
of all the special cases you have to worry about continuing - delay slots,
dual instruction mode, pipeline, etc. The actual processor time consumed
isn't all that horrible, it's just that the exception handling code is
very complex. This isn't to say I think the i860 exception processing is
all that great - I think Intel could have produced a much better design
without a noticable increase in silicon. My suspicion is that they simply
had a lack of software expertise involved in that part of the design.
There is nothing in the current exception processing design, however,
which prevents the chip from functioning correctly in a multiprocessing
application.

I've never looked at the 88000 exception code, but I'm told that it is
quite complex as well. The major difference that I see is that all the
people I've talked to who are using 88000 say that the exception code as
provided by Motorola works fine, and they never had to modify it. In the
case of the i860, the original exception code as provided with Intel
didn't even come close to handling all the cases for continuing from an
exception. Because of this, Alliant spent a great deal of time (1 person
for many months) trying to get this code to work correctly. Had Intel
delivered a working exception handler to i860 customers, the level of pain
and suffering would have been reduced by a few orders of magnitude. This
is one area Intel should try to improve as they come out with future
chips.

So the real problem here was that the chip design mandated a complex piece
of code, which Intel didn't supply. Many customers have spent a lot of money
developing this code themselves, when it would have been more appropriate for
the chip manufacturer to supply it.

>And flushing the cache requires a software loop to map each entry to
>an inaccessible region of memory (no valid bits, it seems).

Well, I'm not sure what Colin meant by "no valid bits". The cache is a
writeback cache, and rather than have a chip function to write back all
the cache lines, the operating system simply has to set things up so that
the normal cache line replacement algorithm will write the dirty line back
to memory, and replace it with an invalid entry. There certainly is a
valid bit; only dirty cache lines actually get written back. In a funny
sort of way, I kinda like this. It seems very RISCy to me - why provide a
special function which doesn't get used that often (only at context switch
time) when you can have the software do it? In the case of the Alliant,
the main memory subsystem couldn't keep up with the chip anyway, so there
wasn't really a speed disadvantage to doing it this way. In systems with
very fast main memory, people might think this was a performance problem,
I can't comment.

I think it's safe to say that this isn't a problem that should cause you to
think twice about using the i860 in your system.

If I had to list the major problems with i860 as they affected Alliant,
they would be:

	1) Exception processing code as provided by Intel was inadequate
	   causing us to dedicate significant amounts of developer time
	   to this. Not a problem with the chip as much as a problem with
	   the way Intel helped bootstrap customers.

	2) No cache coherence scheme making multi-processor implementations
	   suffer severe performance problems (shared data can't be cached).

	3) Time consuming to produce a compiler which can get a significant
	   amount of the potential performance out of the chip. Lets face it,
	   the chip has been out for quite a while, and good compilers are
	   just now appearing.

Of course, you can argue that #2 isn't fair because Intel didn't design
the chip for MP applications. The follow on chip handles that. You can
argue whether that was a smart move when more and more systems are MP
systems. Still, I'd accept that it's not fair to critisize the chip for
this.

What's interesting is that that leaves #1 and #3 which are both software
issues. So perhaps the lesson is that chip manufacturers who want to go
the RISC route should make sure they have the software expertise to do
this, rather than simply push the problem back onto their customers. MIPS
is probably a good example of a company that has a good balance of
software and hardware design experience in their team, allowing them to
ship product to their customers which doesn't take a year to integrate.

I've never worked on a MIPS based product, so perhaps this isn't true.
However, I think the principal is still the same - it's not enough to
produce a hot chip if it takes the customers another year or two to
successfully integrate it into their product and come up with a compiler
which gets a significant percentage of the possible performance. If you do
it that way the product is obsolete by the time system manufacturers get
it to market.

I can assure you that these opinions are my own, and may not be shared by
my employers; past, present, or future...
-- 
uucp: pc@stardent