From owner-freebsd-hackers Fri May 22 15:53:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA07958 for freebsd-hackers-outgoing; Fri, 22 May 1998 15:53:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ducky.net (mike@gate.ducky.net [198.145.101.253]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA07951 for ; Fri, 22 May 1998 15:53:25 -0700 (PDT) (envelope-from mike@ducky.net) Received: (from mike@localhost) by ducky.net (8.8.8/8.8.5) id PAA03154; Fri, 22 May 1998 15:52:03 -0700 (PDT) Date: Fri, 22 May 1998 15:52:03 -0700 (PDT) From: Mike Haertel Message-Id: <199805222252.PAA03154@ducky.net> To: chuckr@glue.umd.edu, jlemon@americantv.com Subject: Re: Original PC and talk Cc: hackers@FreeBSD.ORG, soekris@alameda.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. 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 = long slow operation use R1 R1 = another_long_slow_operation use R1 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message