Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!qantel!hplabs!turtlevax!weitek!mahar
From: mahar@weitek.UUCP (Mike Mahar)
Newsgroups: net.arch
Subject: Re: Delayed Loads
Message-ID: <486@weitek.UUCP>
Date: Tue, 16-Sep-86 13:13:46 EDT
Article-I.D.: weitek.486
Posted: Tue Sep 16 13:13:46 1986
Date-Received: Wed, 17-Sep-86 04:57:08 EDT
References: <5100133@ccvaxa>
Organization: Weitek Corp. Sunnyvale Ca.
Lines: 33
Summary: Delayed loads

In article <5100133@ccvaxa>, aglew@ccvaxa.UUCP writes:
> 
> There has been some discussion of delayed branches in this newsgroup;
> can anybody say anything useful about delayed load/stores? Ie. memory
> access functions that are defined to work the same way as delayed
> branches, not to take effect until after a few more instructions.
> 
> Eg.:	memaddr: .word 2
> 
> 	LOAD r0 := #1
> 	LOAD r0 := [memaddr]
> 	MOV r1 := r0		-- r1 contains 1, not 2
> 	MOV r2 := r0		-- r2 contains 2, the load has completed
> 
Microcoded systems have used delayed loads for some time. Weitek's 7137
and 7136 alu & sequencer use a delayed load model of the form
	address is presented on address bus
	data is loaded on a later cycle

Weitek splits presenting the address and the loading into two seperate
instructions.

The above example is not interruptable. If an interrupt happens between
the second load and the first mov the contents of r0 will be the same
for both moves.
 
-- 

	Mike Mahar
	UUCP: {turtlevax, cae780}!weitek!mahar

	Disclaimer: The above opinions are, in fact, not opinions.
	They are facts.