Date: Fri, 22 May 1998 20:56:02 -0500 From: Jonathan Lemon <jlemon@americantv.com> To: Chuck Robey <chuckr@glue.umd.edu> Cc: Mike Haertel <mike@ducky.net>, hackers@FreeBSD.ORG, soekris@alameda.net Subject: Re: Original PC and talk Message-ID: <19980522205602.26321@right.PCS> In-Reply-To: <Pine.BSF.3.96.980522182616.20133G-100000@localhost>; from Chuck Robey on May 05, 1998 at 07:08:37PM -0400 References: <199805222252.PAA03154@ducky.net> <Pine.BSF.3.96.980522182616.20133G-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980522205602.26321>