Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ucla-cs!ames!ucbcad!ucbvax!decvax!decwrl!pyramid!oliveb!intelca!mipos3!cpocd2!howard
From: howard@cpocd2.UUCP
Newsgroups: comp.arch
Subject: Re: subroutine frequency
Message-ID: <430@cpocd2.UUCP>
Date: Wed, 18-Feb-87 10:50:08 EST
Article-I.D.: cpocd2.430
Posted: Wed Feb 18 10:50:08 1987
Date-Received: Fri, 20-Feb-87 07:02:14 EST
References: <1881@homxc.UUCP> <898@moscom.UUCP> <476@mntgfx.MENTOR.COM> <651@mcgill-vision.UUCP> <425@cpocd2.UUCP> <24929@rochester.ARPA>
Reply-To: howard@cpocd2.UUCP (Howard A. Landman)
Organization: Intel Corp. ASIC Services Organization, Chandler AZ
Lines: 30

In article <24929@rochester.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes:
>In article <425@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes:
>>Isn't this a computer ARCHITECTURE group?  Did you know that HALF of the
>>memory traffic on a VAX-11/780 is data being saved/restored?
>
>Wait a second!  ALL the memory traffic on ANY machine is data that is being
>saved and restored.  That is the purpose of memory.  (Picky, picky :-)

Not really.  Save and restore refer specifically to memory traffic generated
by procedure calls and returns (respectively) in order to prevent one
routine (the callee) from trashing another routine's (the caller's) variables
that are in registers.  Many memory references do not fall into this category.
Normal loads and stores are one example, but also consider instruction fetches.
Are you seriously claiming that an instruction fetch is "data being saved [or]
restored"?

Procedure calls are grotesquely expensive on the most common machines.  A good
rule of thumb for a VAX is that a procedure call takes as long as executing
about 100 computational instructions.  This is why so much of the stdio package
is macros instead of procedures.  There are several ways to try to avoid this
overhead.  One is hardware support for call/return, as in some RISC machines.
Another way is to eliminate procedures from your language; this is what Forth
did with its "threaded code", and is the main reason Forth is so fast.  On a
machine with multiple register windows the speed advantage of Forth would
evaporate; of course you could also implement a hardware stack, which might
increase its advantage!
-- 

	Howard A. Landman
	...!intelca!mipos3!cpocd2!howard