Hi!
Basically a structure like the current zend_op_array would be created on demand by the executor instead of in advance by the compiler.
I guess we could have strings, etc. put in one big string buffer and refer to them by 32-bit index, that would probably work with statically allocated things (like filenames, etc.) But that'd only be useful in 64-bit case, and would just slow down 32-bit (since we probably couldn't afford having 16-bit indexes), which means we should either have separate code for 32 and 64 or have a ton of macros for each string access. I'm not sure that is worth the trouble.
We could do something that could improve things somewhat - namely, organize all static strings into per-op-array string table (in op_array and znode zvals) and refer to them by index. That also would give us some advantages since we could precalculate hashes. IIRC Dmitry Stogov had done some research on that.
You can do it with a length field and a char[1] at the end of the structure. When you allocate memory for the structure, you add some on for the string. Then you copy the string into the char[1], overflowing it. If you need several strings, then you can have several byte offsets, which are added to the start of the char[1] to find the location of the string in question. You can make the offset fields small, say 16 bits.
It's definitely be too much trouble to work with such structures, will lead to a ton of bugs and it'd be a nightmare to manage...
But it's mostly zend_op I'm interested in rather than zend_op_array. Currently if a zend_op has a string literal argument, you'd make a zval for it and copy it into op1.u.constant. But the zval allocation could be
No, zval is part of znode. There might be an allocation on compile stage, etc. but it's temporary - the zval itself is stored inside znode, not allocated elsewhere. See zend_compile.h
avoided. The handler could cast the zend_op to a zend_op_with_a_string, which would have a length field and an overflowed char[1] at the end for the string argument.
Since we need to address zend_op's inside array, variable size ops would be a major inconvenience. Also, since zval is an union, I'm not even sure you'll be saving that much. Constant table though might allow some savings, but would complicate opcodes somewhat.
A variable op size would make iterating through zend_op_array.opcodes would be slightly more awkward, something like:
Note that we need not just iterating but also random access (and no, not only for goto :) - many constructs are compiled into code including jumps).
BTW, as for more effective vars storage - did you look at SPL types, especially SplFixedArray? It looks like exactly what you want with fixed-size storage.
-- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
