Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!brutus.cs.uiuc.edu!jarthur!uunet!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg
From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: 370 Operand Alignment and Page Faults
Message-ID: <PCG.90Feb5150540@rupert.cs.aber.ac.uk>
Date: 5 Feb 90 15:05:40 GMT
References: <9001270059.AA26776@ucbvax.Berkeley.EDU> <49365@sgi.sgi.com>
	<1746@gannet.cl.cam.ac.uk>
Sender: pcg@aber-cs.UUCP
Organization: Coleg Prifysgol Cymru
Lines: 38
In-reply-to: cet1@cl.cam.ac.uk's message of 1 Feb 90 15:18:48 GMT

In article <1746@gannet.cl.cam.ac.uk> cet1@cl.cam.ac.uk (C.E. Thompson) writes:

   In article <49365@sgi.sgi.com> rpw3@rigden.UUCP (Robert P. Warnock) writes:
   >On a related issue, my understanding was (from idle conversation with
   >some IBM guys several years ago) that the 370 architecture needs at
   >least 8 elements in its TLB, and that the TLB must be *at least* 4-way
   >set-associative. The reason is some instruction which copies a source to
   >a destination while referring to a table (some version of Translate-And-Test
   >maybe?). Anyway, the idea was that if the instruction, the source, the
   >destination, and the table entry being used all span pages, then you need
   >at least 8 valid entries in the TLB to make progress on the instruction.

   As regards interruptible instructions, it is sufficient, as you say, that
   the instruction be able to "make progress" with eight valid page table
   entries. In this context, it is significant that those of the 3090 vector
   facility instructions that access non-contiguous vector operands have the
   guarantee "access exceptions are not recognized more than seven element
   locations beyond the current one" (SA22-7125-3 p.2-24).

If somebody is *really* interested in the subject of restartability,
unaligned accesses, and the such, I think that a read of

	R. Ibbet & D. Morris
	"The MU5 computer system"

is fascinating. This was a large supercomputer of the late
60s/early 70s, and had a deep pipeline, a simple architecture,
and virtual memory. All these conspired to create not simple
problems, solved with some elegance (and where else can you find
a discussion of the effect on architecture of the probabilistic
nature of a flip-flop? :->).

The discussion is terse, and I think highly relevant to many
latter day sophisticated machines.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk