Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <3720@goanna.cs.rmit.oz.au>
Date: 11 Sep 90 00:41:03 GMT
References: <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> <8599@tetons.UUCP>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 22

In article <8599@tetons.UUCP>, bdg@tetons.UUCP (Blaine Gaither) writes:
> 4) B5000-B7900 -> A1-A19?  Because all indexed
> memory operations took several ops to form a SIRW (stuffed indirect
> reference word) descriptor on the top of the stack before loading, addressing 
> arrays was painfully slow.

At least on the B6700, array indexing not only didn't build SIRWs, it
*couldn't*.  The instruction sequence for
	X := A[I];
was
	VALC I; VALC A; NAMC X; STOD
	(value call I; value call A; name call X; store destructive)
The instruction sequence for
	A[I] := X;
was
	VALC I; NAMC A; INDX; VALC X; STOD;
	(INDX takes a number and a pointer to a descriptor
	and produces an indexed descriptor, *not* an SIRW)


-- 
Heuer's Law:  Any feature is a bug unless it can be turned off.