Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: comp.arch
Subject: Re: 01/31/87 Dhrystone Results and Sour
Message-ID: <28200008@ccvaxa>
Date: Fri, 20-Feb-87 15:10:00 EST
Article-I.D.: ccvaxa.28200008
Posted: Fri Feb 20 15:10:00 1987
Date-Received: Mon, 23-Feb-87 01:41:45 EST
References: <2348@homxb.UUCP>
Lines: 26
Nf-ID: #R:homxb.UUCP:2348:ccvaxa:28200008:000:1104
Nf-From: ccvaxa.UUCP!aglew    Feb 20 14:10:00 1987


>Another "problem" with Dhrystone which is also present in Dhampstone
>is that since they are single file programs they are subject to
>certain optimizations possible for machines with large numbers
>of registers such as allocating blocks of registers to procedures,
>and a different block of registers to the procedure it calls.
>
>The Stanford MIPS guys are looking at this. But this technique
>doesn't work too well on large real programs which either recurse
>or are multiple program files compiled separately and then
>linked together.
>
>Jan Stubbs    ....sdcsvax!ncr-sd!stubbs

Unless registers are actually only bound at link time.
NOPping out the register save instructions would be trivial,
and not cost too much.

Besides, this sounds a lot like old FORTRAN, with fixed parameter areas
in memory. When memory was too small, overlay.

I read a paper that seemed to imply that Cray was attempting something
similar. Has anything more come of this?

Andy "Krazy" Glew. Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801    ARPAnet: aglew@gswd-vms.arpa