Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!samsung!olivea!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: loop unrolling (was:Re: Register Count) Message-ID: Date: 22 Jan 91 17:26:44 GMT References: <5869@labtam.labtam.oz> <48303@apple.Apple.COM> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 26 Nntp-Posting-Host: odin In-reply-to: baum@Apple.COM's message of 21 Jan 91 03:46:27 GMT On 21 Jan 91 03:46:27 GMT, baum@Apple.COM (Allen J. Baum) said: baum> In article pcg@cs.aber.ac.uk baum> (Piercarlo Grandi) writes: pcg> 2) registers are not free. Every doubling in size of the register file pcg> costs you a lengthening of the cycle time of a few percent; 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? I mean, register files are typically multiported on *the* critical internal buses of the machine. 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. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk