Linus Torvalds (torvalds@osdl.org) on 10/31/06 wrote:
>
>That's what it boils down to. Software should concentrate
>on what software is good at, and hardware should do what
>hardware is good at. It's not an "either or" situation.
>
>It's a symbiosis - a combination of strengths. The things
>that hardware does well are often things that software is
>not so good at, and vice versa.

I'm just going to quote that again, because I think I've
said this before in this forum, but it's worth underlining.

People sometimes seem to see hardware vs software as a bit
of a "battle of the sexes" - as an adversarial kind of
situation. I don't really think that follows at all: it
doesn't follow in biology (it's not "man vs woman"),
and it doesn't follow in CPU design.

Quite often, you would want both hardware and software
doing the exact same optimizations. For example,
there's no question what-so-ever that compilers shouldn't
judge whatever static information they have, and even try
to enrich that information with any means they can, very
much including programmer hints and perhaps dynamic
feedback.

But at the same time, some people seem to be of the totally
insane opinion that just because a compiler does it,
the hardware shouldn't do the same things with its own set
of (different level of) information. The ia64 debacle is
just the most extreme example - "the hardware should not
do XYZ, because we can do that in software".

Yes, compilers can do static alias analysis (although
sometimes they may need hints from the programmer to know
that it's ok). That allows compilers to (for example) find
common subexpressions past memory accesses that they
otherwise wouldn't be able to. But that in no way means
that hardware should think that doing dynamic alias
analysis is "worthless".

Same goes for memory reordering. The compiler does a
lot of static re-ordering of instructions in order
to get better usage patterns (shorter live regions, better
CSE, later stores, easier code sequences, you name it).
But clearly the hardware can do things that a static
compiler could never do, namely take advantage of what
dynamic information it has, most notably whether some of
the accesses can be found early in the L1..

Now, the reason why hardware should then try to hide
the fact that it re-ordered things is a testability and
abstraction issue - the same way that you wish that a
compiler optimization switch should hopefully never cause
actual behavioural differences (it sometimes does,
but it's invariably considered a bad thing either in the
compiler or the source code being compiled), it's just
much better if dynamic optimizations "look" as if they
never happened.

It makes everybody happier. It makes the CPU
verification team happier if they can verify that something
is true "in general" as opposed to having to verify that
everything works "by testing". It makes the software
people happier for the same reason - bugs happen, but the
bugs that are exposed five years later because a CPU does
slightly different things is impossible to even catch
before-hand.

So this really isn't a "software vs hardware" kind of
trade-off where you try to make one do the work of the
other. It's a situation where both sides should just try
to do the best they can. It's not a zero-sum game, where
a deficiency in one balances out a good thing in the
other.

You really can have the best of both world,
because let's face it, it's not even competing resources.
The people who make hardware are not the same ones
that make software. There's no real excuse for trying to
balance them out.

Linus