>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> stack machine -> post-order walk of the tree
>>
>> reg machine -> instruction selection -> register allocation ->
DS> So what? That happens exactly once, in the compilation phase. Yes, it means
DS> compilation will be somewhat slower, but not by much.
DS> As for simplicity, I think Uri was looking at it from the
DS> standpoint of someone writing assembly for the machine by hand,
DS> which is definitely easier.
i was actually referring to writing the op code functions that are in
the vtables. passing registers in and out of them is simpler coding than
munging a stack. i have coded both types in assembler and having
registers makes for cleaner code. and that is a big win for the
internals.
DS> You underestimate the numbers, I think. Even still, so what? I
DS> have two targets, crippled CPUs (x86) and non-crippled CPUs
DS> (everyone else). No matter what I do, I'm not going to get better
DS> than good performance out of an x86. Period. The architecture gets
DS> in the way, and there's not a damn thing I can do about it. On the
DS> other hand, I do have a choice with the rest of the CPUs--I can
DS> get either good or great performance. Seems a bad choice to trade
DS> off great performance on some CPUs for what's likely to be no gain
DS> on the rest.
and the 86's days are numbered with ia64 coming out now. sure x86 will be
around for years to come but it is not the only target out there.
>> Besides I think in the later alphas they added some opcodes to deal
>> with the problem.
dunno about that. i worked on alpha compilers several years ago. OSF-1
was just out then :-)
DS> You'll notice a rather significantly smaller number of register
DS> based opcodes because we don't have to keep pushing stuff over and
DS> over again. There's also much less memory activity. Even if we
DS> make the store operation in the stack-based scheme a single op
DS> (store i) rather than a pair (pushaddr/store) and make the
DS> branch-on-gt operation take a constant (which nobody does to the
DS> best of my knowledge) there's still a lot more thrash going on,
DS> and a lot more opcode overhead. And every opcode has overhead,
DS> there's no way to skip it.
that is why CISC won over stack/accumulator based CPU's. RISC didn't
remove the register concept either. stack based are easier to build (the
freshman CS thing) and simpler to describe. but they require many more
ops to get the same work done. CISC's win was fewer instructiuon fetches
(the major bottleneck in those days). in perl5 the op code loop is the
bottleneck so fewer and more powerful ops will speed that up. dan's
assembler example illustrates that well.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
