NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/arch/11621

Text File | 1992-12-13 | 4.1 KB | 87 lines

Newsgroups: comp.arch
Path: sparky!uunet!usc!sdd.hp.com!hplabs!nsc!decwrl!adobe!usenet
From: [e-mail] (Zalman Stern)
Subject: Re: User visible pipelines vs. user visible memory coherency.
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET NEWS)
Organization: Adobe Systems Incorporated
References: <[e-mail]>
Date: Mon, 14 Dec 1992 03:07:57 GMT
Lines: 75

In article <[e-mail]>
[e-mail] writes:
> History repeats itself?  Many early RISC designs chose to expose timing
and
> pipeline constraints to the software.  It was up to software not to access
> data before it arrived, for example.
>
> Successive generations of RISC designs have moved that responsibility back
to
> hardware.  The original Stanford MIPS had no pipeline interlocks at all -
if
> the software didn't play by ALL the rules, it got nonsense.  The first
> generation of the commercial MIPS architecture cut the constraints down to
> two:  You had to wait one extra cyle before trying to use the results of a
> load or a multiply, if I remember right.  The second generation of
commercial
> MIPS has even added hardware interlocks for those.

First off, even the Stanford MIPS project interlocked on cache misses for
loads. (Its not really possible to build a processor that works without
this.) Hence I consider the "no interlocks" line bogus. Secondly, the
commercial MIPS I ISA has a load delay slot and a branch delay slot.
(Multiply/divide is interlocked.) Good arguments for these are along the
lines that you will not build machines that execute dependent instructions
back to back in these cases and software (i.e. compilers) can easily handle
them. The load delay slot has an impact on code density though and hence was
removed.

> Delayed branches were a great idea for a while, but recent designs, such
as
> Alpha, have eschewed them.

Without any real compelling arguments that I've heard. (Dick Sites saying
"Any architecture with a 25 year life span won't have delayed branches." is
not a compelling argument.) Note that such decisions depend a lot on other
elements of your architecture. (E.g. compare-and-branch instructions vs.
condition codes.) Delayed branches may be a win for one architecture but not
for another.

> The IBM RS/6000 design has NO "correctness" constraints - the RISC-style
> optimizations are important for performance, but even without them the
program
> runs.

There are correctness constraints for some of the privelleged instructions
on the original RS/6000. Delayed instructions are not a major cause of
program errors anyway though. On MIPS systems, the assembler takes care of
it all for you so it just doesn't matter.

> Now we are trying the same thing with memory consistency.  Ten years from
now,
> will we be looking back at those funny experiments of the early '90's that
> (a) made the machines such a bitch to program; and (b) didn't really help
> beyond a generation or two of design anyway?
>                             -- Jerry

As I said above, single delay slots do not make a machine "a bitch to
program." It comes down to a performance analysis. You win with delayed
branches unless you are going to throw a fair bit of hardware at instruction
prefetching, in which case delayed branches don't matter one way or the
other.

The issues for memory consistiency are quite different though. First of all,
we a generally talking about tens or hundreds of cycles instead of one or
two. Secondly it is more difficult to predict data access patterns in
concurrent code than pipeline stall behavior. (Note that software controlled
caching has been seriously studied as well and suffers similar problems.)

One problem with software controlled memory synchronization is any barrier
instructions you insert eat instruction issue bandwidth. Hence its easy to
lose any gains you would get by having simpler/faster hardware.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson