Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdcad!bcase
From: bcase@amdcad.UUCP
Newsgroups: comp.arch
Subject: Re: Word vs. Byte Orientation; some kernel #s
Message-ID: <16295@amdcad.AMD.COM>
Date: Wed, 22-Apr-87 13:02:58 EST
Article-I.D.: amdcad.16295
Posted: Wed Apr 22 13:02:58 1987
Date-Received: Fri, 24-Apr-87 01:29:37 EST
References: <16122@amdcad.AMD.COM> <311@winchester.UUCP>
Reply-To: bcase@amdcad.UUCP (Brian Case)
Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca.
Lines: 26

In article <311@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes:
>>Plus, the stack cache decreases
>>the load/store percentage overall with respect to a machine (like the
>>MIPS) with "only" 32 fixed registers.  We seem to have about half as
>>many loads/stores, but it varies (and my compiler ain't the best, e.g.
>>no register coloring for memory-resident stuff).  This lower load/store
>>percentage might be another reason that word orientation is more appropriate
>>for the Am29000 ....
>
>Actually, there is some evidence that the marginal utility of extra
>registers in machines like IBM 801, MIPS R2000, etc [i.e., 32-register
>ones] drops off in the 24-28 range.

I believe your numbers are right.  Without the stack cache model,
I think the Am29000 would have load store percentages very close to
those for machines like the MIPS, and indeed, more than 32 registers
would not be of much use for one process (but could be used to improve
process context switch times somewhat).  A stack cache performs, if
you will, a "dynamic" interprocedual analysis.  Not really, but some
of the benefits of real interprocedural analysis are gained.

One of the things I know for sure is that some potential Am29000 users
are really happy about the large register file, but not necessarily
because of its ability to implement a stack cache.

    bcase