Newsgroups: comp.arch
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Interlocked Pipelines - basic questions
Message-ID: <1991Mar26.213709.9246@zoo.toronto.edu>
Date: Tue, 26 Mar 1991 21:37:09 GMT
References: <1991Mar26.171547.2400@sj.nec.com>
Organization: U of Toronto Zoology

In article <1991Mar26.171547.2400@sj.nec.com> koll@NECAM.tdd.sj.nec.com (Michael Goldman) writes:
>... I read also that MIPS, which originally stood for
>Microprocessor without Interlocking Pipeline Stages (I think) has introduced
>interlocked pipelines.

MIPS stands for two things:  a Stanford project some years ago, which did
indeed use MIPS as an acronym with the expansion you give, and a company,
which doesn't.  The company's products have always had interlocking of
certain kinds.

>1.  What does the interlocking refer to ?

To having an instruction which needs not-yet-available data wait around
until the data is on hand.  The alternative is to require the compiler
to ensure that the situation never happens, by generating code that
explicitly stalls when needed results would not be ready in time.

>2.  Why is it considered good or bad ?

It's good if delays are unpredictable, because otherwise the compiler
would have to insert a worst-case stall every time.  It's bad because
it adds hardware complexity.  The Stanford project established that
you *could* do without it, given a smart compiler and predictable delays.
Unpredictable cache delays and the desire to make compiled programs move
between different versions of the machine without recompilation tend to
encourage commercial hardware builders to use interlocks.

>3.  What, if any, are the implications for interrupt handling ?

None that I can think of offhand.  Pipelining does tend to make interrupts
fun, but whether the pipeline is interlocked or not is less significant.
-- 
"[Some people] positively *wish* to     | Henry Spencer @ U of Toronto Zoology
believe ill of the modern world."-R.Peto|  henry@zoo.toronto.edu  utzoo!henry