On 09/04/01 Uri Guttman wrote:
> does it really matter about comprehension? this is not going to be used
> by the unwashed masses. a stack machine is easier to describe (hence all
> the freshman CS projects :), but as dan has said, there isn't much
> mental difference if you have done any serious assembler coding. is the
> pdp-8 (or the teradyne 18 bit extended rip off) with 1 register (the
> accumulator) a register or stack based machine?
It's easier to generate code for a stack machine and parrot is supposed to
be a target for several languages: make it hard and only perl6 will target parrot.
That said, I haven't seen any evidence a register based machine is going to
be (significantly?) faster than a stack based one.
I'm genuinely interested in finding data about that.
> but it doesn't matter what the underlying hardware machine is. that is
> the realm of the c compiler. there is no need to think about the map of
> parrot to any real hardware. they will all have their benefits and
I brought the topic up because it was given as a benefit of the parrot
register architecture. An issue is that, if parrot is going to run
also low-level opcodes, it better know about the underlying arch
(well, it would be faster than the current perl anyway, but
that's for another reason).
> that more than one temp slot is a big win IMO. with stack based you
> typically have to push/pop all the time to get anything done. here we
> have 32 PMC registers and you can grab a bunch and save them and then
> use them directly. makes coding the internal functions much cleaner. if
> you have ever programmed on a register cpu vs. a stack one, you will
> understand. having clean internal code is a major win for register
> based. we all know how critical it is to have easy to grok internals. :)
The only difference in the execution engine is that you need to update
the stack pointer. The problem is when you need to generate code
for the virtual machine.
> DS> No. Absolutely not. The primary tenet is "Keep things fast". In my
> DS> experience simple things have no speed benefit, and often have a
> DS> speed deficit over more complex things. The only time it's a
> DS> problem is when the people doing the actual work on the system
> DS> can't keep the relevant bits in their heads. Then you lose, but
> DS> not because of complexity per se, but rather because of programmer
> DS> inefficiency. We aren't at that point, and there's no reason we
> DS> need to be. (Especially because register machines tend to be
> DS> simpler to work with than stack machines, and the bits that are
> DS> too complex for mere mortals get dealt with by code rather than
> DS> people anyway)
>
> amen. i fully agree, register machines are much simpler to code with. i
> don't know why paolo thinks stack based is harder to code to.
stack machine -> post-order walk of the tree
reg machine -> instruction selection -> register allocation ->
> on some machines like the alpha, getting single bytes is slower than
> fetching 32 bits.
Too bad less than 1 % of the people that will use parrot have
an alpha or a Cray. Optimize for the common case. Besides I think
in the later alphas they added some opcodes to deal with the problem.
lupus
--
-----------------------------------------------------------------
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
