I've been playing around with converting PHP bytecode to Parrot bytecode so I
sent a mail asking for information about the internals of their virtual
machine.

Less than helpful. Umm, yes. Rude, borderline. Urge to kill rising.
Definitley.




----- Forwarded message from Jade Nicoletti <[EMAIL PROTECTED]> -----

Date: Sun, 30 Sep 2001 12:38:47 +0200
To: Simon Wistow <[EMAIL PROTECTED]>
From: Jade Nicoletti <[EMAIL PROTECTED]>
Subject: Re: [PHP-DEV] PHP/Zend Virtual Machine Documentation
User-Agent: Mutt/1.3.20i
Organization: Nicoletti Net Services

On Wed, Sep 26, 2001 at 04:22:17PM +0100, Simon Wistow wrote:
> I'm playing around with translating PHP byte code to the Parrot Virtual
> Machine - the new virtual machine being designed and built for Perl 6
> specifically with translation between languages in mind (there's already
> work being done on Python VM and JVM conversions).

What do you actually want to do? What are your goals?

> Many of the opcodes look like they'll be similar (I'm presuming that the
> only opcodes are the ones that are defined in zend_compile.h) but I'm
> looking for more documentation on what some of the rest actually do
> (ZEND_(BEGIN|END)_SILENCE for example), what sort of operands they take
> and the how the rest of the Zend virtual machine is made up (from the
> code it looks like it's stack based - Parrot is going to be register
> based which should make things interesting).

The following expression
        @ expr
becomes
        ZEND_BEGIN_SILENCE
        opcodes to evalute the expression (errors won't get printed)
        ZEND_END_SILENCE

Read the source.

> Also I'm looking for the easiest way to get hold of some intermediate
> code or bytecode for simple scripts so that I can gradually start adding
> conversion routines. What's the best way to do this? Hack together code
> from the rest of the source tree or can I get stuff from the
> cache/optimiser?

Answer my questions first.


> only opcodes are the ones that are defined in zend_compile.h) but I'm
> looking for more documentation on what some of the rest actually do
> (ZEND_(BEGIN|END)_SILENCE for example), what sort of operands they take
> and the how the rest of the Zend virtual machine is made up (from the
> code it looks like it's stack based - Parrot is going to be register           
> based which should make things interesting).

The following expression
        @ expr
becomes
        ZEND_BEGIN_SILENCE             
        opcodes to evalute the expression (errors won't get printed)
        ZEND_END_SILENCE

Read the source.

> Also I'm looking for the easiest way to get hold of some intermediate
> code or bytecode for simple scripts so that I can gradually start adding
> conversion routines. What's the best way to do this? Hack together code
> from the rest of the source tree or can I get stuff from the            
> cache/optimiser?

Answer my questions first.

> Has anybody else tried doing anything like this? Am I smoking huge
> quantities of crack?

I don't know :)

-Jade.


----- Forwarded message from Jade Nicoletti <[EMAIL PROTECTED]> -----

Date: Tue, 2 Oct 2001 13:47:29 +0200
To: Simon Wistow <[EMAIL PROTECTED]>
From: Jade Nicoletti <[EMAIL PROTECTED]>
Subject: Re: [PHP-DEV] PHP/Zend Virtual Machine Documentation
User-Agent: Mutt/1.3.20i
Organization: Nicoletti Net Services

On Sun, Sep 30, 2001 at 04:18:33PM +0100, Simon Wistow wrote:
> > What do you actually want to do? What are your goals?
>
> The Parrot virtual machine is being specifically designed to be seperate
from
> the Perl language - for whatever reasons the powers that be (from here on to
> be referred to as TPtB) have decided that they want a common language
runtime
> in much the same way as the Microsoft CLR is.
>
> Like I said, they probably have their reasons. It probably involves a bet of
> some sort.
>
> Anyway, I used to code a lot of PHP (back around PHP/FI 2.0 and PHP3) when I
> did the whole web site thing and I have Copious Free Time [tm] at the moment
> so I thought I'd see how easy it was to try and get

No answer so far, just background information.


> PHP running on Parrot so ...
>
> foo.php -> [ php interpreter ] -> [ intermediate code ] -+-> PHP VM
>                                                          |
>                                                          '-> Parrot
>
> And thus have the same code running on both the PHP VM and Parrot. Or maybe
> Perl6 code running on the PHP VM later (when the language's been designed)

This is a bit vague, but I think that I understand.

It won't work as you suggested with your ascii diagram. Or if you get it to
work, it's a kluge. The right thing to do is most probably to completely
get rid of /Zend and replace it with a Parrot based engine. This way you
can run the same PHP code on both engines.

You can't run Perl6 code using the Zend engine (ZE) because it was not
designed as a generic VM. You can't get the ZE to mimic Perl's runtime
behaviour whereas Parrot can adapt foreign language semantics.


> > Read the source.
>
> Yeah, ok, that was just an example. I though I'd ask if there was any opcode
> documentation before I started wading through code.

There is no opcode documentation. There is no documenation about any ZE
internals. There is even no API documentation (at least not a current/complete
one).


> > Answer my questions first.
>
> Umm, ok. I think I have.

As I've said, opcode translation alone gives you not much, you have to
completly replace the ZE. This needs huge amounts of work. The following
things have to be done:
        - scanner/parser/compiler (using as much of Parrot/Perl as possible)
        - reimplement the needed runtime functionality that is not provided
          by Parrot to get PHP semantics. That is:
                - php data types, operations
                - missing opcodes (?)
                - ?
        - vtables to integrate this functionality into Parrot
        - an API that is compatible to Zend's (for the PHP core and the
          extentions)


> Which means, basically, I need a good supply of PHP bytecode and preferably
> some way of generating it easily so that I can write test scripts easily,
grab
> the byte code and and run it through my converter and then into Parrot and
see
> if it works.

That way you can't use predefined functions (_no C extensions_), there are
no predefined variables ($HTTP_GET_VARS etc) and you can't use "complex"
data types (susch as arrays).

It meens, you can't use it for much more than just a "hello world" script.


-Jade.

-- 
: nature notes for the apocalypse

Reply via email to