On May 21, 2007, at 5:56 PM, Will Coleda wrote:
I was talking to a colleague (who wishes to remain anonymous), and
s/he had a list of questions about the state of parrot that I think
should end up in the FAQ or elsewhere in the repo. I wanted to post
them here to get some discussion - I don't have answers to many of
these questions myself.
---
1. Why Parrot?
http://www.parrotcode.org/docs/intro.html:
"Parrot is designed with the needs of dynamically typed languages
(such as Perl and Python) in mind, and should be able to run programs
written in these languages more efficiently than VMs developed with
static languages in mind (JVM, .NET). Parrot is also designed to
provide interoperability between languages that compile to it. In
theory, you will be able to write a class in Perl, subclass it in
Python and then instantiate and use that subclass in a Tcl program."
a. What, precisely, about Parrot makes possible more efficient
execution of a dynamically typed language than would be the case with
the JVM or the CLR?
Parrot is a register based machine instead of a stack based machine.
This is the way your computer is designed. Although many architectures
heavily use the stack, registers are far more efficient. Using a
register based machine makes JITing executable code far more efficient
to come far closer to machine compiled speeds.
But that mainly affects statically typed languages, such as a parrot
without pdd15. WRT dynamically typed languages, parrot's designed for
it. It's as simple as that.
b. Whatever that is, how will it adversely impact the execution of
statically typed languages, including type-inferred languages?
If we don't force many high level components on all languages(such as a
scalar is a scalar and is not an integer), and provide a capacity for a
language to create it's own types(new pmc's), they can provide the
functionality they need without excessive overhead of other operations.
But this is where "one vm for them all" comes to hurt us, as well. In
trying to support all languages, and provide at least the capacity for
all languages, we hurt our optimization for one specific language which
is what many languages do.
I imagine parrot won't have a significant issue with statically type
languages, but that it will be more of an issue of the compiler itself.
Parrot should be able to run java fast and efficently, so long as it's
compiled from java to pir, instead of running java bytecode, or
compiling java bytecode to pir.
c. How will this impact the execution of statically typed code in
Perl, Python and other targeted languages?
Most problems will be from coding styles most likely. Interoperability
between functional programs will probably be a non-issue, but two
different oo languages(and thus two inheritance models) will likely
impact performance more. But this is an issue of having one vm for
all.
2. General Features
a. How will Parrot support reflection and attributes?
b. How will Parrot support generics types?
c. How will Parrot support interface types?
d. What kind of security models will Parrot support?
e. How will Parrot support small-footprint systems?
Perhaps miniparrot can help take care of this. If miniparrot's a
miniature parrot, and perhaps supporting only those features that that
language needs, we might be able to get a parrot suited for embedded
systems. PMC's not needed won't be compiled in, the runcores other
than the default could be left out, and parrot's size could shrink
dramatically.
f. How will Parrot support direct access to "unmanaged" resources?
Is this like UnmanagedStruct?
g. How will Parrot facilitate distributed processing?
With native threading support.
3. Parrot PMC Issues
The Parrot PMC vtable provides a large number of optional functions,
which PMCs can either implement or not. If not implemented, they will
throw an exception at runtime.
a. What support will Parrot provide a compiler to interrogate a PMC at
compile time to know what it actually implements?
All of these functions appear to be predefined because there is no
mechanism for extending this functionality at runtime. It appears that
compilers will be limited to implementing functionality that is
defined in the vtable. The vtable contains the common operations
required by certain languages.
The only extendibility that I know of is via PIR, or a dnypmc library.
But the vtables are primarily for interoperability with everything.
Methods can still be addded to a pmc to provide additional needs.
b. How will Parrot handle languages with operations that are not
provided?
http://www.parrotcode.org/docs/vtables.html:
"To be perfectly honest, this is a slightly flawed example, since it's
unlikely that there will be a distinct "Python scalar" PMC class. The
Python compiler could well type-inference variables such that a would
be a PythonString and b would be a PythonNumber. But the point remains
- incrementing a PythonString is very different from incrementing a
PerlScalar."
c. How will Parrot address cross-language semantics?
The purpose of a common calling convention, and vtables, are to address
cross language semantics. All languages will implement the basic
things in the same way. It's not a "our way or the high way" but
rather a "our way is the best way for parrot."
d. Will each language have to provide its own support for interacting
with PMCs for other languages?
No, the PMC's will do that themselves. Getting the PMC's is another
story. A language is reponsible for it's cross language semantics.
But parrot is designed for the widest possible case. Many languages
limit valid characters that a subroutine can use, but parrot does not.
But as long as "common" cases are adhered to, most problems will not
exist, e.g. no unicode whitespace in a subroutine name.
e. How will a PerlScalar interact with a PythonString?
The best method would probably convert both down to a String, do
whatever operation, and convert up to whatever is request. But, for
optimization, multimethod vtables could be used to provide custom
behavior. I know src/pmc/complex.pmc has some examples of multimethod
vtables.
f. What will happen when a PythonString is incremented in Perl code?
Parrot call's PythonString's increment vtable. Perl doesn't have an
increment, but PerlScalar does. Python doesn't have an increment, but
PythonString does. Now, if the PMC doesn't implement that vtable
function, an exception is thrown, but Parrot still tries to call it.
Comparing the vtable for a PMC to the JVM and CLR base Object classes,
the PMC is essentially an "abstract" class with dozens of
"unimplemented" methods, while Java's Object provides (and implements)
the following public methods:
equals getClass hashCode notify notifyAll toString wait
Discounting the methods related to Java's peculiar threading
implementation, that's:
equals getClass hashCode toString
Similarly, the CLR's CTS Object provides:
Equals ReferenceEquals GetType GetHashCode ToString
g. Why is it a good thing that PMCs essentially non-contractual
abstract base classes that define a lot of functionality without
implementing it?
In some instances, this is a benefit. Suppose you want an
auto-iterating string array. For the most part, it's an array with
normal array properties. But if you get it's string value, it iterates
over the next one. If you set it's string value, maybe it splices that
value into the array. Having both array and string properties is
beneficial in this case.
But the downside is most things, such as an Integer, don't need many of
the vtables provided. In fact, if you look at the c output of a pmc
file, you'll see that every vtable is created. I imagine it's more for
simplicity and speed than for memory(both executable and ram) than
anything else.
h. Why is there no first-tier depth in Parrot's type system, such as:
PMCString, PMCIntger, PMCNumber, ...
You mean like String, Integer, Number, Array, etc?
4. Parrot VM Issues
Parrot provides what it calls "registers" with no guarantee that these
map to hardware registers.
a. Will any registers ever map, in a Parrot-controlled way, to hardware
registers?
Yes. If a subroutine uses less than or equal to the number of
registers on an architecture, the entire subroutine can be converted
into native code, leaving parrot out entirely. Using a PPC system is
better than an i386 system in this case, since it has more registers.
Even if the subroutine isn't compiled entirely to native code, portions
of that code will be compiled to native code as best as possible.
The very basis of parrot's jit system is that both parrot and the
native system use registers, and that keeping data in registers helps
to improve speed greatly.
b. How can a compiler efficiently allocate registers if it does not
know which ones will map to hardware registers?
I don't believe there's a capacity for doing this at the moment. It's
up to parrot to decide how much is jitted and how much isn't.
5. Parrot Design Issues
Parrot has many operators and number of Core PMC types for them to
operate on. Parrot has so many operators that it appears to be using
them instead of having a standard library. This is markedly different
than the CLR and JVM systems.
a. Why was this done this way?
If you look at the number of ops x86 has with an FPU, there are a
massive number. The x87 cpu has an opcode for sine, just like parrot
does. Many of parrot's opcodes are for accessing features of parrot
through pir. Many of parrot's operations can't be easily taken away.
One of the likely reasons is speed, but what things are the questioner
curious about?
b. What is the basis for deciding what will be an operator?
c. How can substantial quantities of additional functionality be added
to this design cleanly?
New vtable's can be added by editting vtable.tbl, new ops can be added
by adding to src/ops/experimental.ops, new pmc's can just be added to
src/pmc afaik. New charsets in src/charset, new jit architectures
under src/jit(just add --jitcapable and it'll try to compile it in).
I'd say it's a fairly clean layout for expanding things. There's even
the capacity for adding a new garbage collected.
--
Will "Coke" Coleda
[EMAIL PROTECTED]
