Path: utzoo!attcan!uunet!ginosko!uakari.primate.wisc.edu!ames!ncar!gatech!amdcad!cayman!tim
From: tim@cayman.amd.com (Tim Olson)
Newsgroups: comp.arch
Subject: Re: Bandwidth Wasters Hall of Fame for comp.arch
Message-ID: <27460@amdcad.AMD.COM>
Date: 24 Sep 89 20:04:29 GMT
References: <13744@well.UUCP> <4186@bd.sei.cmu.edu> <10732@eerie.acsu.Buffalo.EDU> <125156@sun.Eng.Sun.COM> <11539@burdvax.PRC.Unisys.COM>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Distribution: na
Organization: Advanced Micro Devices, Austin, TX
Lines: 28
Summary:
Expires:
Sender:
Followup-To:

In article <11539@burdvax.PRC.Unisys.COM> barry@PRC.Unisys.COM (Barry Traylor) writes:
| Stack machines OPTIMIZE locality of reference.  By doing such, a processor
| does not need to have massive quantities of registers available.

Except that the locality of reference for stack machines is too
narrow, mainly restricted to the first few items on the top of the
stack.  Compiler optimizations such as common subexpression
elimination and loop-invariant code-motion want to stuff useful values
into fast-access locations for reuse, but if you don't have a
mechanism for specifying these locations in the instruction set, then
the benefit of these optimizations is reduced.

| On a
| context switch, or better yet, a process switch (which on most machines
| involves 2 context switches), how long does it take to store and restore
| all of those registers?

The tradeoff here is how often you perform  a context switch vs. how often
you perform some other operation that can benefit from general-purpose
registers (and whether the context switch time meets any real-time
requirements placed on it).




	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)