basic parrot questions
Why would a software machine closely emulating CISC architecture be expected to execute as efficiently on RISC and CISC machines? Does it make any sense to create a low-level machine modeled on one-architecture instead of a high-level architecture which can flexibly optimize to either architecture? Also, I thought Parrot was not stack-based If that is the case then why does Overview.pod say this: Registers will be stored in register frames, which can be pushed and popped onto the register stack. For instance, a subroutine or a block might need its own register frame.
Re: basic parrot questions
On Mon, Dec 03, 2001 at 08:31:00AM -0800, Terrence Brannon wrote: Also, I thought Parrot was not stack-based If that is the case then why does Overview.pod say this: Registers will be stored in register frames, which can be pushed and popped onto the register stack. For instance, a subroutine or a block might need its own register frame. This describes the operation of a register based architecture. That is, the current state of the registers (register frame) are pushed and popped as necessary (typically upon function invocation). A stack architecture does not have general purpose registers that are individually addressable. The Forth VM (implemented in silicon by i-forget-whom) contains a stack of ~16 data and ~16 code operands, and no registers. There is no way to address the individual contents of the stacks, save the topmost element (or two) of the stack. Z.
RE: basic parrot questions
Terrence Brannon: # Why would a software machine closely emulating CISC architecture # be expected to execute as efficiently on RISC and CISC machines? We're not necessarily expecting it to run as efficiently. We're just expecting it to run efficiently enough. # Does it make any sense to create a low-level machine modeled on # one-architecture instead of a high-level architecture which can # flexibly optimize to either architecture? Yes, because we've tried higher-level machines and were always either killed by stack thrash or other issues uniquely destructive to a high-level machine's operation, or buried in complicated code. Optimizers are good, but they still can't recognize a stack machine when they see one. :^) We don't expect to have our architecture map directly on to the physical architecture of any machine. We don't expect any machine to have 128 registers, 64 of which are pointers, 32 ints and 32 floats. Registers are basically just conveniently numbered slots in memory. # Also, I thought Parrot was not stack-based If that is the case # then why does Overview.pod say this: # # Registers will be stored in register frames, which can be pushed and # popped onto the register stack. For instance, a subroutine or a block # might need its own register frame. That's just a convenience in case you manage to fill up the registers and need s'more. Many architectures have something like this--IIRC Sparc (I think it's Sparc, but I'm not sure) has a way to 'rotate' the register set and get the first half of the registers moved to the last half of the slots; the first half of the slots are then filled with fresh registers. But Sparc (or whatever it is) is definitely a register-based architecture. We actually do have a data stack too, for passing arguments that won't fit in the first five registers or for saving data for later--we're still register-based because most of our operations are on registers. --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 Nothing important happened today. --George III of England's diary entry for 4-Jul-1776
Re: basic parrot questions
At 08:31 AM 12/3/2001 -0800, Terrence Brannon wrote: Why would a software machine closely emulating CISC architecture be expected to execute as efficiently on RISC and CISC machines? Because it means that the machine doesn't do that much work itself, passing most of the work off to the opcode functions, which are in C and thus already native code. Going RISC-like in an interpreter (And yes, Shiram, I am using that properly... :) is a profoundly foolish thing--you're guaranteed that you'll chew up huge amounts of time with opcode dispatch overhead. Yuck. For hardware, RISC makes sense up until the point where your CPU speed outstrips your memory bus bandwidth and you spend a significant chunk of your time twiddling transistors and waiting for data. Instruction decoding and dispatch is essentially free, since you can do it in parallel with other operations. For VMs it doesn't make sense because instruction dispatch is *not* free. (This is where JITs get a lot of their speed win--if all your JIT does is eliminate instruction dispatch you can get a factor of 10x-20x speedup) Minimising dispatch costs means minimizing the number of executed opcodes, which means you want fatter opcodes so you can burn CPU time doing work, not housekeeping. Does it make any sense to create a low-level machine modeled on one-architecture instead of a high-level architecture which can flexibly optimize to either architecture? What, do you mean does it make sense to build a VM rather than something else? What, pray, would you propose as an alternative? Also, I thought Parrot was not stack-based If that is the case then why does Overview.pod say this: Registers will be stored in register frames, which can be pushed and popped onto the register stack. For instance, a subroutine or a block might need its own register frame. Because not being stack based means we don't do nonsense like: PUSH $foo GETVARPTR PUSH $bar GETVARPTR PUSH $baz GETVARPTR ADD STORE to execute $foo = $bar + $baz. Just because we're not stack based doesn't mean we don't have a stack. Stacks are useful things. (Go ahead, find a CPU that doesn't have one...) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
