As already stated, this site is not a good place to have this discussion since it is OT for here, and the key people you should ask (like Simon Cozens) aren't around.
Again, as already stated, if you phrased some of these questions as questions rather than as statements and arguments, people would probably be more kindly disposed to you.
In any case your statements betray a fundamental lack of knowledge. Perl and Python already work in terms of bytecode machines. Both of them already fit the "virtual super CISC machine" description. Perhaps if you understood that, then you would be in a better position to understand Parrot.
Now the description "super-CISC" should be a tip-off to something important. The idea is that the byte-code allows concise descriptions of the kinds of operations that people do inside of scripting languages. What that means is that a single operation in this byte-code, such as a hash lookup or a regular expression match, may be very complicated indeed in terms of any realistic "Assembly language". These are very high level instructions, which are very complicated. The virtual interpreter will see these and proceed to do something involved and complex. Since the vast majority of the execution time is therefore spent executing the instructions rather than interpreting them. This means that the overhead of interpreting instructions is small, and therefore efficiency of execution has little to do with how directly the bytecode maps to the native architecture, be it CISC or RISC.
In short if you tried to understand what Parrot was doing rather than proceeding to flame upon your initial misunderstandings, you would understand that they actually have a high-level architecture. High-level or low-level, it can be described as an assembly language of a kind. But since it is high-level, it has super complicated instructions, hence their description.
Now to answer the other two questions. There are many excellent reasons to not use Scheme for what they are doing. Here is a sample:
- The concepts that they are looking to "chunk" on are not directly implemented in Scheme, and they have implementations already in C to work from.
- They want to have an implementation in which it is very easy to link to external libraries, and such libraries are most portably linkable in C. Building their stuff in C makes that goal easier to accomplish than it would be if they had to link through the indirection of an implementation built in Lisp.
- Far most importantly, they are an open source effort. That means that they have to go where the contributers they want are, and not vice versa. It is critical for what Parrot is doing that it attract people who hack on perl and python. They know that the key people with that experience are competent at C. They would be far less likely to contribute to a project written in Scheme. If a bunch of Lisp hackers wanted to write their own virtual machine, they might indeed work from Scheme. The techniques to build a language on top of a Lisp are widely known and have been used many times. (eg That is how Smalltalk was developed.) But if they did that, they would be virtually guaranteed to not get core Perl developers interested.
And lastly, whether Parrot is stack based. If Parrot is going to support continuations, then it won't be globally stack based because a stack cannot model the kinds of program flows a continuation requires. Instead each continuation gets its own stack, and so you still need an operation to push and pop to the current register stack. But there will also be operations to switch which stack is the current register stack. | [reply] |
1. I think you are more likely to get good responses to these questions/criticisms if a) you state them as questions and not as criticisms b) you post them to the appropriate Perl 6 mailing list. While discussing Perl 6 is definitely appropriate on PM, I don't see that this is the *best* place for such discussions. I'm guessing the bulk of the people who can make intelligent arguments on behalf of the decisions made do not frequent PM enough to catch this. Maybe I'm wrong, we've certainly had some interesting new Monks join lately.
1.a. Maybe it would be a good idea for Perl Monks to get a new section for Perl 6? Where discussions like this and maybe links to other Perl 6 info would be gathered up... I'd volunteer to work on it, but I'm more likely to learn Ruby than to worry about Perl 6 in the next 12 months. :D
2. You're obviously familiar with the Perl 6 development sites and the community efforts surrounding same. Surely some of these questions are answered in either the Apocalypse/Exegesises, the RFCs, or on the discussion lists (especially those related to design/development)...
Just my two cents. | [reply] |
princepawn is unlikely to get good responses by posting on the perl mailing lists because these issues have already been beaten to death by the developers. If he bothered to read per6-internals and perl6-language he wouldn't have had a reason to post at all. Yes, I'm posting an advanced form of a RTFM (directed at princepawn, not you :).
Don't be too quick to rule out chances that people involved in perl6 aren't here as well. Simon Cozens may or may not be but BrentDax certainly is - check out his posts on implementing the new regexp engine for some really good insight into how regexps work.
I have also seen quite a few PerlMonks lurking on the lists and the bugtraq. This doesn't suprise me. We all want perl 6 here now, so quite a few of us are keeping an eye on what's coming our way.
____________________
Jeremy
I didn't believe in evil until I dated it.
| [reply] |
And the obvious question is: why would a software machine closely emulating CISC architecture be expected to execute as efficiently on RISC machines?
princepawn you disappoint me. I used to be impressed by the clear thinking in your arguements. Nobody said that a CISC set would run well on a RISC machine. If you find someone claiming that, please post a link because I would be fascinated to see the reasons for someone claiming it. However the stated reason for a CISC VM with lots of registers is that there the VM shouldn't be crippled by bad Intel design decisions. I don't recall RISC being mentioned specifically, and I think it's fairly obvious that RISC machines are just going to have to keep up as best they can.
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?
In case you missed my last paragraph, the stated intent of the parrot developers is to create a medium-to-low-level architecture that can be optimised in a machine-specific way. Why didn't you read the stated intent of the developers? You put words into their mouths-the wrong words.
Given that the proposed "low-level" architecture is probably too low for flexible optimization,
Register based machines were chosen because of the large amount of literature on optimising register based machines. Now if you read posts by the developers (as you clearly haven't), they plan to do much optimisation in the parse tree, and then save the source code along with the byte code for chances at further optimisation. You didn't read that bit, did you?
Also, I thought Parrot was not "stack-based" If that is the case then why does Overview.pod say this:
Register based machines have stacks. You don't actually know anything at all about assembler or machine design, do you?
____________________
Jeremy
I didn't believe in evil until I dated it. | [reply] |
"Stack machine" describes a machine, or a virtual machine described by an instruction set, that doesn't use register numbers. Parrot's instruction set, however, does use register numbers. Therefore, it is not a stack machine.
Shame on you for not researching this....
-- Chip Salzenberg, Free-Floating Agent of Chaos | [reply] |