Path: utzoo!utgpu!cunews!bnrgate!bigsur!bnr-rsc!bcarh185!schow
From: schow@bcarh185.bnr.ca (Stanley T.H. Chow)
Newsgroups: comp.arch
Subject: Re: speculative execution
Message-ID: <3445@bnr-rsc.UUCP>
Date: 12 Oct 90 16:27:44 GMT
References: <42062@mips.mips.COM>
Sender: news@bnr-rsc.UUCP
Reply-To: bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow)
Organization: BNR Ottawa, Canada
Lines: 68
Summary:
Followup-To:
Keywords:

In article <42062@mips.mips.COM> mash@mips.COM (John Mashey) writes:
>As another example, consider the effects of hoisting a load
>instruction, which is something you'd like to do in a machine
>with out-of-order characteristics, especially if it has multiple
>memory paths.  Here are a few cases of interest:
>
>	a) The load is an uncached load to a volatile device register.
>	Hoisting is of course a no-no, as this will drive OS programmers
>	nuts, and in fact, must be carefully synchronized with
>	surrounding operations, or else.

This should not be particularly hard, just use "volatile" in C. (I know,
the zillions of lines of existing code may break, but as some people say -
those programs are brain-damaged :-).

It is also possible for (very clever) hardware to handle it with some
sort of MMU attribute per page. Several existing processors already have
this. Speculative loads could proceed blindly until it hits one of these
stop bits. The affected load would be put "on-hold" pending a "really-do-it"
or a "forget-it". (So it's hard, but we gotta use up those millions of
transistors :-)
>
>	So, of course, you don't hoist these things, or allow the hardware
>	to do any hoisting for you via speculation.  For instance, in
>	the code that looks like:
>	if (flag)
>		x = p->device1;
>	else
>		y = p->device2;
>	Any hardware that speculatively issues EITHER of the assignments
>	before being sure which one, may well have trouble if the
>	read actually gets to the memory system.  In fact, I think this
>	means that any uncached load stops any speculative path,
					   ^^^
>	because you dare not issue it for the side-effect.

This is not so.

An uncached load (at worse) stops *its* speculative path. In other words,
paths without uncached loads can still proceed. E.g.,

if (flag)
	x = p->device1;
else
	x = somelocal;

The fetch of "somelocal" can happen before the "if". In general, after
figuring out side effects and aliasing, the only restriction should be
that volatile accesses cannot "pass" each other.

Also, as suggested in the paragraphs above, with sufficiently clever
hardware, one can still "conservatively" speculatively fetch volatile 
addresses. (Hmm, is that an oxymoron?)
>
>	b) Clearly stores can't be speculatively issued.
>	Even cached loads may take care, any time a load can cause
>	a fault, such as an MMU miss, or an out-of-range access
>	(like to location 0 on many machines.) [..]

Again, issue the store early to get through the address translation and
protection checking, then wait for the "really-do-it". 



Stanley Chow        BitNet:  schow@BNR.CA
BNR		    UUCP:    ..!uunet!bnrgate!bcarh185!schow
(613) 763-2831               ..!psuvax1!BNR.CA.bitnet!schow
Me? Represent other people? Don't make them laugh so hard.