Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23221
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <002901c673bc$88901e30$5c8be5a9@ohr.berkeley.edu>
Reply-To: "Sara Golemon" <pollita@php.net>
To: <internals@lists.php.net>
Date: Tue, 9 May 2006 16:01:22 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Compile Time Resolution of Constants
From: pollita@php.net ("Sara Golemon")

I noticed some time ago, while browsing around ZE sources that as of 5.1,
constants are resolved to literals at compile time when possible.  What I
didn't notice was that this is only done if the constant in question has the
CONST_CT_SUBST flag set (which *NO* constants in the stock distribution have
set).  Tossing this constant onto an assortment of internal constants yields
just the result I'd expect; i.e. given a script like:

echo M_PI;

The resulting opcodes go from:

ZEND_FETCH_CONSTANT ~0 'M_PI'
ZEND_ECHO ~0

to:

ZEND_ECHO 3.1415926535

All well and good, but it begs the question: Why isn't CT substitution
treated as the default for persistent (internal) constants, with an optional
NOSUBST flag given as an option?  The performance difference between the two
wouldn't be large, but every little bit helps.  The one problem I see with
CT substitution is encoders where the meaning of certain (important)
constants would change from system to system, but that sort of exception
rule sound more like a job for an INI switch than a general disabling...



While y'all kibitz about that, here's another one:  Class constant
resolution isn't happening during compile time at all currently (with the
exception of static initializers).  Since class constant resolution requires
not one but two hash table lookups, this is actually more useful than normal
constant's would be.

One of the tricky bits to making this work is the way that class constants
are picked up in the parser:   fully_qualified_class_name
T_PAAMAYIM_NEKUDOTAYIM T_STRING   where fully_qualified_class_name reduces
from a rule that generates a ZEND_FETCH_CLASS opline.  To be able to perform
compile-time resolution of class constants, it'd need to be possible to
rewind the prior op from within zend_do_fetch_constant() when resolution
succeeds (a messy and not-nice approach).  The compromise I came up with was
to delay the invocation of zend_do_fetch_class() by turning the parser rule
into simply:    T_STRING T_PAAMAYIM_NEKUDOTAYIM T_STRING    Then dispatching
from zend_do_fetch_constant() back to zend_do_fetch_class() only when
necessary.

Here's a diff for review:
http://www.libssh2.org/patches/ct_class_constants.diff
(I didn't include the .c translation so you'll need bison to build this)

-Sara