Date: Fri, 22 May 1998 19:08:37 -0400 (EDT) From: Chuck Robey <chuckr@glue.umd.edu> To: Mike Haertel <mike@ducky.net> Cc: jlemon@americantv.com, hackers@FreeBSD.ORG, soekris@alameda.net Subject: Re: Original PC and talk Message-ID: <Pine.BSF.3.96.980522182616.20133G-100000@localhost> In-Reply-To: <199805222252.PAA03154@ducky.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 May 1998, Mike Haertel wrote: > Chuck Robey wrote: > >It uses those invisible internal registers to store things coming from > >or going to real registers. The strategy is far more useful when there > >are more registers _to_ rename. > > You are deeply mistaken. No, I'm not at all. Register renaming isn't done by the compiler, it's done by the processor, so you can't say (as you do in your last paragraph) that the compiler can handle it. First, the reason for lots of registers is to cut memory accesses, and just makes the dependency problem more difficult. Your last example, where you only have 1 register, is too unreal to cope with (you need 2 sources and one sink to have _some_ reality), assume you did have 3 registers. The problem of keeping track of only 3 registers is far simpler than keeping track of, say, 64 registers. This is fairly obvious. Having those lots of registers makes the compiler's job of marshalling arguments easier, and allows the compiler to set things up for maximum parallelization, but the processor still has to do the dependency checking itself, the compiler doesn't do that. If the compiler orders things wrong, efficiency suffers. If the processor orders things wrong, the resulting data is incorrect. It's the processor's job to make a parallel instruction stream work exactly as if it was a serial stream. I simplified my original post, because I didn't want to take everyone thru this, but I wasn't deeply mistaken. > The purpose of register renaming is to eliminate "antidependencies". > An antidependency is when you have a long-latency operation that > writes a registers, followed by another long latency operation > than writes the same register. E.g.: > > R1 = long_slow_operation > use R1 > R1 = another_long_slow_operation > use R1 > > Register renaming puts each subsequent write to R1 in a different > physical register, and keeps track of which physical register > holds the most recent value of R1. After being renamed, the > above code might look like: > > R1 <physical register 100> = long slow operation > use R1 <use physical register 100 as the source of R1 data> > R1 <physical register 101> = another_long_slow_operation > use R1 <use physical register 101 as the source of R1 data> > > The idea is that the two long slow operations can now proceed in > parallel because they are writing different physical registers. > > Now you should realize that register renaming is most > important on a machine with FEW architectural registers. > > Extreme example: suppose you had a machine with only one > register. Without register renaming, each operation that > wrote that register would have to wait for the previous > operation to complete. With register renaming, the > machine would only have to wait when there were actual > data dependencies (younger operation wants to read the > result of older operation). > > On the other hand, if a machine has LOTS of architectural > registers (like the Alpha) then the compiler can put each > successive instruction's result into a different register. > So even if the machine does no register renaming, it can > proceed without stalling for antidependencies, because > the compiler can ensure that there aren't any simply by > not writing any one register too often. Effectively the > compiler can do register renaming (think of it as result > renaming) in software. So there is less of a need for > hardware register renaming. > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980522182616.20133G-100000>