Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!sunybcs!bingvaxu!leah!itsgw!batcomputer!pyramid!voder!apple!baum
From: baum@apple.UUCP (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: What should be in hardware but isn't
Message-ID: <6449@apple.UUCP>
Date: Wed, 31-Dec-69 18:59:59 EDT
Article-I.D.: apple.6449
Posted: Wed Dec 31 18:59:59 1969
Date-Received: Mon, 12-Oct-87 00:49:27 EDT
References: <581@l.cc.purdue.edu> <18336@amdcad.AMD.COM> <582@l.cc.purdue.edu> <14750@watmath.waterloo.edu> <826@sugar.UUCP> <912@hall.cray.com>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 24

--------
[]

A while back, somebody wrote:
>BTW, there is an address modification procedure which is missing on all
>machines I have seen except the UNIVAC's.  That is to consider the register
>file as a memory block and allow indexing on it...

Somebody else wrote:
>The PDP-10 also did this.  The first 16 memory locations were the registers.
>There was an option to get fast (non-core) memory for these few bits.

And >Brian Utterback replied:
>Another advantage the PDP-10 had by mapping the registers to the memory space,
>other than indexing, was in execution.  You could load a short loop into the
>registers and jump to them!  The loop would run much faster, executing out 
>of the registers.  

This is not the case exactly. EMACS did, in fact, use this trick to
significantly speed up such things as 'search', but when the KL-10 &
-20 processors came out, this trick ran SLOWER than running code out
of regular RAM.

--
{decwrl,hplabs,ihnp4}!nsc!apple!baum		(408)973-3385