Re: non load/store architecture?


David Brown wrote:
Brandon J. Van Every wrote:

CISC, i.e. having arithmetic instructions that can access memory, i.e.
the x86 architecture we love to hate, is hard to optimize. Your
statement, "simplifies register assignment for (the compiler)" only
applies if you have no intention of producing optimal code.

One of the liabilities of RISC, i.e. load/store, is that programmers
don't tend to write code with any kind of load/store discipline. They
write whatever the hell they feel like writing. If it's the garden
variety industrial "*** code," it will contain sequences of memory
accesses that cannot be changed. At least, that the compiler can't
prove are safe to change. Programmers can write great code on a RISC
architecture if they're RISC-aware. LOAD everything up, do the math,
STORE the results. But generally they aren't RISC-aware, and don't
want to be.

Especially in a PC marketplace dominated by the x86. At DEC, we ran
into this issue all the time when porting device driver code to the DEC
Alpha. It's also why the Alpha's x86 emulation was never all that
great. x86 code, in general, simply couldn't be re-scheduled in RISC
load/store fashion. The Alpha may have been the world's best CPU in
its day, but it didn't have a commensurately kick*** memory
controller, so we suffered.

x86 is still here and the Alpha's dead. This is a clear case of "Worse
Is Better." That is, you spread your marketshare by being 1st with the
quck-n-dirty version. Also, if your inelegant solution runs on average
machines, you spread faster. Those who hold out for "Better Is Better"
tend to marginalize their marketshare. Look at what DEC was: great
engineering company, couldn't market its way out of a paper bag. Look
at the Wintel hegemony: still with us today, still has the same
business model of "Worse Is Better."


Cheers,
Brandon Van Every


x86 is not a bad architecture because of being a non-load/store
architecture, or because it is CISC. There is nothing inherently bad
about being CISC, and nothing inherently good about RISC.

I have the bias of a performance jock. I define "good" as
"optimizeable." Yes, RISC is inherently better than CISC for
optimization; that is the point of RISC. I also think it is easier to
write optimizing compilers for RISC than for VLIW, judging by the
industry's experience with the Itanium. But at least, VLIW attempts to
regiment instruction scheduling. That's what you have to do to get
performance. The CISC "whatever length, whatever latency" stuff does
not cut it.

They give
different scope for different sorts of implementation, but it is
possible to make a bad RISC ISA or a good CISC ISA (the 68k/ColdFire is
an example of a very nice CISC ISA).

Define "nice." Maybe you think it's nice because it's low power or
easy to program or something.

The x86 was widely held to be a
poor and limited design when the 8086 first came out, and modern x86
chips have a terrible architecture (but with some very nice
implementations) as a result of incremental steps keeping backwards
compatibility with such a bad starting point.

Yep, Worse Is Better.


Cheers,
Brandon Van Every

.