Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Tek) 9/26/83; site orca.UUCP
Path: utzoo!linus!security!genrad!decvax!tektronix!orca!andrew
From: andrew@orca.UUCP (Andrew Klossner)
Newsgroups: net.arch
Subject: Re: uP caches, cont'd.
Message-ID: <385@orca.UUCP>
Date: Mon, 12-Dec-83 11:21:12 EST
Article-I.D.: orca.385
Posted: Mon Dec 12 11:21:12 1983
Date-Received: Wed, 14-Dec-83 01:46:42 EST
References: <12@haddock.UUCP>
Organization: Tektronix, Wilsonville OR.
Lines: 25


	"The 360/91 and perhaps other machines tried to do this to
	memory references in general ..."

The designers of the IBM 360/91 not only tried but succeeded.  A
standard assembler programming trick was to compress instruction loops
down to 16 bytes or less, so that the machine could keep the entire
loop in its internal registers and not have to fetch them from memory.
This feature combined with the pipelining (multiple instructions
executing simultaneously) reduced the cycle time for many loops down to
the time for the "branch backward" instruction that terminated them.

Of course, pipelining can be a disaster in an educational environment.
For many years the 360/91 was the only machine available to novice
programmers, who had to deal with vague messages: "something was wrong
at approximately this point in your program ... the specific fault
could have been any one of many problems (odd addressing, write to
foreign memory, etc.).  Many students quickly learned to terminate all
PL/I statements with two semicolons, rather than one; the "null
statement" between the two semicolons was translated into a single
NOOP, which causes the 360/91 to clear its pipeline, so that errors can
be isolated to a specific PL/I statement.

  -- Andrew Klossner   (decvax!tektronix!orca!andrew)      [UUCP]
                       (orca!andrew.tektronix@rand-relay)  [ARPA]