Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28336
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain realplain.com from 69.179.208.43 cause and error)
Message-ID: <008801c76629$a32ce830$0201a8c0@pc1>
To: <internals@lists.php.net>
Date: Wed, 14 Mar 2007 06:12:21 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Optimize parsing of negative numbers?
From: php_lists@realplain.com ("Matt Wilmas")

Hi all,

I realized awhile ago that PHP creates a ZEND_SUB opcode even with a literal
number after the '-' (-123), which of course causes the number to be negated
each time it's used during runtime.  So a few months ago, and again
recently, I took a look at the parser grammar to see if I could get these
"common_scalar"/numbers to be negated once in parse/compile stage (like
"static_scalar") but didn't really get anywhere. :-/  Just "reduce/reduce
conflicts" even if the rules seem like they should work (but I have no idea
about this Bison stuff!).  Well, there was one way I eliminated the
conflicts, but it seems kinda sloppy and no idea if it would actually work.

For the Bison gurus, is there a simple way this could be done with a little
grammar rearranging?  Of course there would be a runtime improvement with
negative numbers, but it should also compile faster, skipping opcode
creation, etc.

BTW, for "expr_without_variable",   '+' expr   generates ZEND_ADD.  As far
as I know there's no point to that, right? ;-)  Its action should simply be
$$ = $2;


Thanks,
Matt

P.S.  Here on Windows, I wouldn't be able to test any parser changes
anyway -- Bison is somehow creating wrong files or such since if it's run
with a default zend_language_parser.y, I then get "unexpected ..." parse
errors that are obviously bogus.  Any ideas?