Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!ucsd!sdcc6!beowulf!djohnson
From: djohnson@beowulf.ucsd.edu (Darin Johnson)
Newsgroups: comp.arch
Subject: Re: Controller registers vs. Speculative Execution
Keywords: superscalar I/O
Message-ID: <15676@sdcc6.ucsd.edu>
Date: 17 Jan 91 03:56:57 GMT
References: <14829@celit.fps.com>
Sender: news@sdcc6.ucsd.edu
Organization: CSE Dept., UC San Diego
Lines: 39
Nntp-Posting-Host: beowulf.ucsd.edu

In article <14829@celit.fps.com> hutch@fps.com (Jim Hutchison) writes:
>I've been hearing a bit about new processors which do "speculative execution".
>...
>If it write a value to a control register on a controller, something may
> happen. If it read a control register, something may happen.

IO has a tendency of always intruding itself into nice clean theories.
The major problem is that the semantics of memory change completely
when using mapped IO.  For example, two reads of the same location
without a write to that location in between may possibly result in
different values being read.  This same sort of problem occurs when
designing caches (esp.  with programmable IO controllers such as
channels).  The problem isn't as great with RISC-style CPU's that can
place an instruction in the delay slot after a branch, since the
compiler can choose a 'safe' instruction.

There are several solutions or techniques that limit the problem, I
won't list them all (even if I knew them all).

First, is to use explicit IO instructions, and to stall speculative
branch execution when one of these is reached.  Also, IO can be mapped
into an address space that the CPU knows about (high order bit set),
and stall the same way.

Second, many of these machines are designed to be attached processors,
with IO only to the frontend or IO ports (context switching can really
bog things down...).  So this isn't a major problem.

Third, devices could be controlled via an IO processor, which handles all
the gory details.

Other solutions possible...

>Jim Hutchison		{dcdwest,ucbvax}!ucsd!fps!hutch
>Disclaimer:  I am not an official spokesman for FPS computing

-- 
Darin Johnson
djohnson@ucsd.edu