Hi Sara, It is interesting and very clear patch. Probably you idea can be extended to support regular globals too. I mean $GLOBALS["name"]. BTW I am not sure this patch will give significant speedup, because locals are used most often then globals, and your patch adds small overhead for them. Did you benchmarked your patch?
According to ZEND_BEGIN_SILENCE, just try to run simple script <?php $x = @$y;?> with and without this check. In case of missing check, real $y fetch is performed in ASSIGN operator after ZEND_END_SILENCE, so we see error message. Thanks. Dmitry. > -----Original Message----- > From: Sara Golemon [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 16, 2007 1:58 AM > To: Sara Golemon > Cc: internals@lists.php.net > Subject: [PHP-DEV] Giving Globals the CV treatment [WAS: > Runtime JIT Proposals] > > > > The solution I'm tempted to pursue for this is to back up > yet another > > step and make autoglobals be CVs by extending the > zend_compiled_variable > > struct to contain a flag indicating how the var should be > fetched (the > > determination for which happens during fetch_simple_var during the > > compilation. This would then yield an opcode stack like > the following: > > > Okay, here's a shockingly simple patch for allowing auto > globals to be > treated as CVs. The one question mark I've got in here is: > Why the last > check in fetch_simple_var_ex() for the ZEND_BEGIN_SILENCE > opcode? This > seems completely unnecessary from what I can tell and shouldn't bar a > variable (global or not) from being treated as a CV... > > Am I missing something really obvious? > > -Sara > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
