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)