Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!zaphod.mps.ohio-state.edu!usc!apple!baum From: baum@Apple.COM (Allen J. Baum) Newsgroups: comp.arch Subject: register access time critical? Message-ID: <48369@apple.Apple.COM> Date: 22 Jan 91 23:21:52 GMT References: <48303@apple.Apple.COM> Reply-To: baum@apple.UUCP (Allen Baum) Organization: Apple Computer, Inc. Lines: 39 [] >In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >On 21 Jan 91 03:46:27 GMT, I said >baum> I couldn't let this pass by. Doubling a register file size slows >baum> down register access a few percent. It may or may not slow down >baum> cycle time-- when register access is in the critical path. > >Conceded, yet maybe you could have let it pass; how useful is it to >consider the case where the register file *isn't* in the critical path? Very. >I mean, register files are typically multiported on *the* critical >internal buses of the machine. The critical buses are not the internal ones, generally, and when they are, they are not the register access ports. >I can only say that it is hard for me to imagine, not being an hardware >designer, relevant cases where the register file is not in the critical >path or does not influence it. I'd like the opinion of someone who has >dealt firsthand with this kind of issue. I think that if there are >relevant cases, they could teach us something. All the information that I have is that this is exactly the case. I have talked to people involved with rather hairy designs, and never has register access been on the critical path. In one of the recent SPARC designs reported at last year's ISSCC, they even did a reg-read/add in a single pipe stage, and if anyone was going to be hurt by register access, it would be a register window machine like SPARC. I have specific examples, but I'll let MIPS & SPARC & AMD designers speak for themselves- they're probably reading this. -- baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum