Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!ucsdhub!sdcsvax!ucsd!ucbvax!agate!bionet!csd4.milw.wisc.edu!nic.MR.NET!shamash!raspail!dsc
From: dsc@raspail.UUCP (Dave Christie)
Newsgroups: comp.arch
Subject: Re: questionable nos.--SPARC vs. MIPS on gcc
Summary: MIPS load delay fill-in IS execution out-of-order
Message-ID: <1117@raspail.UUCP>
Date: 24 Dec 88 12:35:41 GMT
References: <82150@sun.uucp> <22745@apple.Apple.COM>
Organization: Control Data Canada
Lines: 33


In article <22745@apple.Apple.COM>, baum@Apple.COM (Allen J. Baum) writes:
A lot of stuff that I quite agree with, and: 

> The no-ops are architectural because MIPs thought it unlikely that any
> implementation could ever get away without an extra cycle in those
> circumstances. Note that SPARC incurs these penalties. I predict that
> they will not go away for quite a while.
>    Specifically: Load/use interlock. The only way to avoid this is execution
> of instructions out of order, which requires that multiple instructions be
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> examined in parallel and a lot more. It this can be done, then the "Noop" can 
  ^^^^^^^^^^^^^^^^^^^^
> effectively be executed out of order as well, and its cycle will disappear.

This is precisely what the MIPS code reorganizer does - changing
the "natural" order of instructions to eliminate the load delay penalty
as much as possible by examining several instructions at once.
I realize you were probably referring to hardware code reorganization at
run-time, which is indeed a complex matter.  But reorganizing of object code
prior to execution does much the same thing without the complex hardware.
Granted, there are cases where reorganization can be done at runtime that
cannot be done beforehand (depending on how much hardware complexity you
want to throw in), but the global view a compiler has can allow optimizations
that the instruction issue logic can't do.  For the most part, hardware to
reorganize code at runtime to fill in one cycle of load delay would probably
fail to do so (causing a stall) as often as the MIPS code reorganizer has
to insert a noop.  So MIPS is already doing what you suggested. 
-- 
Dave Christie, Control Data Canada, Mississauga, Ontario
dsc@raspail.UUCP   or   {backbone}!uunet!rosevax!shamash!raspail!dsc
"Any opinions expressed herein do not necessarily reflect those of CDC,
and for that matter, probably no one else."