Re: non load/store architecture?


Andrew Smallshaw wrote:

Another thing is the way you are looking at this. The question to
ask is why _go_ for a load/store architechure, not why not. I'm
not arguing for a moment that the load/store architechure is without
merit, it's just not obvious for the inexperienced. Having arithmetic
instructions that can access memory simplifies register assignment
for the programmer (or compiler) and if a value is only needed once
in a certain area of code, then all other things being equal it
has much to commend it. IOW, it's other factors that influence the
decision to go load/store and not vice versa.

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

.