From owner-freebsd-hackers Fri May 22 18:57:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA11648 for freebsd-hackers-outgoing; Fri, 22 May 1998 18:57:03 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA11620 for ; Fri, 22 May 1998 18:56:48 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id UAA14814; Fri, 22 May 1998 20:56:34 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id UAA26297; Fri, 22 May 1998 20:56:03 -0500 Message-ID: <19980522205602.26321@right.PCS> Date: Fri, 22 May 1998 20:56:02 -0500 From: Jonathan Lemon To: Chuck Robey Cc: Mike Haertel , hackers@FreeBSD.ORG, soekris@alameda.net Subject: Re: Original PC and talk References: <199805222252.PAA03154@ducky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: ; from Chuck Robey on May 05, 1998 at 07:08:37PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On May 05, 1998 at 07:08:37PM -0400, Chuck Robey wrote: > 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. Uh, it can be done by both. I'll refer you to Hennnessy & Patterson, 2nd edition, (which I assume you have), page 232: [ Register renaming can be done either statically by a compiler or dynamically by the hardware. ] > 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 Not at all. The HP MPE 3000 series is a stack-based machine, and only has one "register"; the accumulator. Now, before you accuse me of dredging up ancient history, I'll point out _another_ stack based architecture: Java. > parallelization, but the processor still has to do the dependency > checking itself, the compiler doesn't do that. If the compiler orders Again, it depends. Merced, for example, is supposed to depend heavily on the compiler to arrange things, so there does not have to be as much hardware to do dynamic checking. Tinker, based on the HP-playdoh approach, is another architecture that also depends on the compiler to explicitly mark parallelism in the instruction stream. > 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 think that you have this backwards. The processors' job is to exploit the instruction-level parallelism inherent in a serial stream. Modern chips do this by speculative execution, branch prediction, and out-of-order execution. Hardware register renaming _is_ more important for those cases where there are fewer architectural registers, because it allows the processor to re-order the instruction stream to exploit maximal parallelism. For those chips with a larger architectural register set, the compiler can re-order the instructions so that there are fewer WAW and WAR hazards. While the "reservation stations", to use the Tomasulo terminology, do store things "coming and going to real registers", they increase the overall parallelism of the chip by in-effect providing more registers for use. Please refer to H&P, page 251, 259, and 310 for a discussion of reservation stations, and reorder buffers. To quote H&P again: [ The reservation stations extend the real register set via the renaming process ]. For a good overview of the process, I would also recommend J.E.Smith, G.S.Sohi, "The Microarchitecture of Superscalar Processors", Proceedings of the IEEE, December 1995. it does provide an overview of the AMD K5 architecture (as well as some other processors. For an overview of Intel's chip, I would suggest: L.Gwennap, "Intel's P6 uses Decoupled Superscalar Design", Microprocessor Report, February 1995. Although you can probably find some better references since then. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message