Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100423
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.169 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <d7cc2a67-be8d-91ea-a6ee-21abb5d7d412@tekwire.net>
References: <BY2PR02MB2989D1A6035072A57D098DDAC970@BY2PR02MB298.namprd02.prod.outlook.com>
 <CAF+90c-mHpF8N7tUiggUkO0m2Pxevz3OZ70TBKc1gFkZ2abzPQ@mail.gmail.com>
 <CAJHtznxHu3RzGbkmTj0K7ut+=cgaXNUwLo2kHzjVzecyOQqfCg@mail.gmail.com> <d7cc2a67-be8d-91ea-a6ee-21abb5d7d412@tekwire.net>
Date: Wed, 6 Sep 2017 13:20:21 -0400
Message-ID: <CAESVnVrN00i-0PTU=Pg9aRLon=fVkjpNFTkcMyi3TJ0=03y=EA@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>
Cc: Zeev Suraski <vsuraski@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	Zeev Suraski <zeev@zend.com>, Arvids Godjuks <arvids.godjuks@gmail.com>, 
	Dan Ackroyd <danack@basereality.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Providing built-in functionality written in PHP (was
 RE: [PHP-DEV] [VOTE] UUID)
From: pollita@php.net (Sara Golemon)

On Wed, Sep 6, 2017 at 11:30 AM, Fran=C3=A7ois Laupretre
<francois@tekwire.net> wrote:
>> Secondly, ideally, this shouldn't just be a mechanism to mix and match C
>> and PHP - but actually make it easy for people to write pure PHP code
>> that'll become integrated to the PHP binary.  PCS can practically alread=
y
>> support that, we'd just need some build magic to take .php files during
>> build, create the PCS wrapper for them and compile them right in.  Have
>> some sort of a standard where builtin.php files inside extension
>> directories are included, or something of the sort?  Definitely requires
>> more thinking, but if this becomes a basic building block of PHP as I
>> think
>> it should, I wouldn't want end users to have to manually compile PHP cod=
e
>> into .phpc or create .c wrappers - but have it as automatic as possible.
>
>
> Parsing the code, extracting symbol names, and generating all needed
> information as a C include file is done offline because it requires a
> working PHP interpreter. So, it cannot be done at build time (when compil=
ing
> the core). It is done the same way as the core files generated using PHP
> (like zend_vm_execute.h/zend_vm_opcodes.h): each time, he modifies the PH=
P
> code, the developer must regenerate the '.phpc' files. The '.phpc' file w=
ill
> be managed in git and will be included in the source distribution. So,
> nothing changes for the end user : phpize/configure/make. The same for
> extensions included in the core: '.phpc' files are included in the source
> distrib. I'll also probably include this code (re)generation in 'phpize'.
>
> So, the most difficult part, AFAIK, is how to make class and function cod=
e
> persistent, or load it just in time, or a combination of both. The case o=
f
> constants is more complex and out of scope at this time. I hope I have so=
me
> times during the next weeks to implement a prototype, at least for
> functions.
>
I believe I brought this up during the previous round of PCS
discussion, but HHVM does this with its SystemLib already.

In short (ignoring the per-extension systemlibs for the moment), all
the files named in hphp/system/php.txt* are bundled into a single file
at compile time and that file is dropped into a .text section in the
binary.  Then on startup, that section is inspected and fed to the
compiler.  There's implementations in HHVM for doing this on Linux,
Mac, and Windows.  I can't say for sure that all of PHP's supported
OSs have a solution available, but the big three certainly do.

-Sara

* The files to be included are explicitly named in order to guarantee
load order and optimal hoistability.  This enumeration may or may not
be necessary based on how PHP's binds symbols.

** HHVM places some restrictions on what goes into a systemlib file.
  1. No side-effects/psuedo-main.  This is probably already a
requirement of PCS, just pointing it out.
  2. Files either need namespace blocks (with curly braces), or an
implicit empty namespace will be applied to them.
  3. No file-level namespaces or declare statements.