Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!husc6!bloom-beacon!gatech!amdcad!news From: news@amdcad.AMD.COM (Network News) Newsgroups: comp.arch Subject: Re: Are all RISCs the same? Message-ID: <22860@amdcad.AMD.COM> Date: 7 Sep 88 01:32:34 GMT Article-I.D.: amdcad.22860 References: <58@zeno.MN.ORG> <6903@aw.sei.cmu.edu> Reply-To: tim@delirun.amd.com (Tim Olson) Organization: Advanced Micro Devices, Inc., Sunnyvale CA Lines: 33 Summary: Expires: Sender: Followup-To: In article <6903@aw.sei.cmu.edu> firth@bd.sei.cmu.edu (Robert Firth) writes: | In article <58@zeno.MN.ORG> gene@zeno.UUCP (Gene H. Olson) writes: | | >* The Motorola, Intel, MIPS, SPARC, HP, and IBM RISC | > architectures are incredibly similar. In their basic | > instruction sets, none of them has any significant | > advantages over the other. | | Sorry, Gene, I'm going to disagree with your first point, and hence | with your conclusions. These machines differ in many respects. | | (a) Some have register window systems. This is a disastrous design | error that will ultimately doom them. In particular, the greatly | increased context-switch time, and the unpredictability in the | cost of a simple procedure call, make register-window machines | unsuitable for hard real time applications. Oh, I suppose that by the same reasoning, any machine with caches, virtual memory, or even "page-mode" RAMs is also doomed. Sigh. I guess it's back to the old TMS9900 architecture with no registers to get in the way of that fast context switch and predictability. ;-) How did you measure this "greatly increased context switch time?" There is typically a whole lot more going on during a true context switch than dumping and restoring register contents. In addition, many times it is interrupt latency, not context switch time, that is important. Here, many "register window RISCS" like the Am29000, SPARC, and 80960 have an advantage, in that typically there is a window or reserved register area for the interrupt handler to run in without saving *any* registers. -- Tim Olson Advanced Micro Devices (tim@delirun.amd.com)