Thies C. Arntzen writes:
> hi,
>
> we've started a project (will have a web-page soon) that aims to
> port the php-language (www.php.net) to run on top of parrot.
Cool!
> we've written some initial code and i'm kinda stuck while
> writing the codegen (i target imc)
>
> my problem is that php is typeless. i am writing code to to some
> basic type-recognition in my ast to be able to leverage the much
> speedier I S and N types in parrot, but for obvious reasons i
> have to make the php basic type an PMC. problem now is that
> using pmc for everything will make execution much much slower
> that it could be.
Could be? How? The only way it could be faster from the codegen level
is if you have a really good data flow analyzer that can tell that
something is *only* going to be doing a certain kind of operation. That
is a hard, and in general impossible, problem.
> my compiler currently translates:
>
> <?php
> for ($i = 0; $i < 100; $i = $i + 5.5) {
> echo "hallo";
> }
> ?>
>
> to:
>
> [buncha pir code]
>
> (i know it can be made better - working on it)
Actually that was pretty good for an early version. You could help IMCC
out by not creating those PerlUndefs until you're going to assign to
them.
> - but the basic dilemma is obvious: $i starts as an INT and becomes a
> FLOAT at runtime. so my compiler made it a PMC. (i know that i'll at
> one point have to write my own PMC for the PHP base-type, but for now
> PerlUndef works for me).
>
> because pmc as so much slower that native types i loose most of
> parrots brilliant speed due to the fact that i don't know the
> types at compile-time.
Yep, you do. That is the caveat of dynamic languages.
> i believe you'll face the same problem once perl6 becomes a reality on
> parrot
We know about this, too. And that's one of the reasons Perl 6 is
introducing an optional type system: so the programmer can tell the
compiler when it's allowed to use the [ISN] types instead of PMCs, when
they need to be fast (tight loops and such). Without any user guidance,
everything would have to be a PMC (save a few special cases).
> so here's my question (i've only been on perl6-internals for some
> week, so sorry if this has been discussed in depth before):
>
> would't it make sense to introduce one additional new type into
> parrot that can "morph" between the normal types (I, S, N, P)?
Yeah, it would! We call those PMCs.
Most of the reason [ISN]s are so fast is because of the Just-In-Time
compiler. I don't know whether there are plans to make the JIT dynamic,
in that it could detect that we have a JITtable PMC on our hands and JIT
the following section of code with respect to that. My guess is that
there are no such plans, or that it's impossible to do well.
Your morphing type doesn't make any sense, when you look at how things
are compiled into byte code. You're asking it to be compiled
differently based on the run time type, which is somewhat of a temporal
paradox.
>
> something like (i call the type VAL):
>
> typedef enum { INT, NUMBER, STRING, ... PMC } ValType;
>
> typedef struct {
> ValType type;
> union {
> INTVAL i;
> NUMBER n;
> STRING s;
> ...
> PMC p;
> } u;
> } VAL;
>
> and add support for this in the executor in the most efficient way.
Which would be about as efficient as PMCs currently are.
>
> if you think this is unneeded could you explain how you are
> planning to make untyped languages run really fast on parrot and
> what direction i have to take to use that technique? (PMC will
> always carry the vtable jump overhead, so they will be slower
> than what perl or php use currently in the inner execution loop)
Vtable jump isn't really that much overhead in a language like C.
Parrot's already running pretty fast. We're making things fast by
keeping it in mind while implementing it, including a rich opcode
and vtable so the number of said slow dispatches are small, among other
various things that I don't know. Maybe Dan will chime in here :-)
It's great that you're doing PHP for Parrot.
Luke
>
> i'd also like to add that eg PHP has different semantics when you do binary
> operations on strings that perl has so this VAL type would have to be
> as flexible as a PMC. (PHP would have to use a different implementation
> than Perl6 or Python)
>
> thies
> --
> Thies C. Arntzen - Looking for all sorts of freelance work - just ask..
> http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ
