Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:77050 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16525 invoked from network); 3 Sep 2014 19:57:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Sep 2014 19:57:51 -0000 Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:49818] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 12/20-15506-BB277045 for ; Wed, 03 Sep 2014 15:57:48 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 33) id AA75F6D209D; Wed, 3 Sep 2014 21:57:44 +0200 (CEST) Received: from 79.197.68.242 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Wed, 3 Sep 2014 21:57:44 +0200 Message-ID: <1d4bfa1ec8fef435b66b180f688cde35.squirrel@webmail.klapt.com> In-Reply-To: <30b36d3944d6cfb3b2dfaafbf41cc69c.squirrel@webmail.klapt.com> References: <2afc5a878ff4c780c74f4604f77525c1.squirrel@webmail.klapt.com> <3bc533250c01664354fce3e4167ca78b.squirrel@webmail.klapt.com> <30b36d3944d6cfb3b2dfaafbf41cc69c.squirrel@webmail.klapt.com> Date: Wed, 3 Sep 2014 21:57:44 +0200 To: "Anatol Belski" Cc: "Dmitry Stogov" , "Anatol Belski" , "Pierre Joye" , "PHP internals" , "Nikita Popov" , "Xinchen Hui" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Re: 64 bit string offsets From: anatol.php@belski.net ("Anatol Belski") On Mon, September 1, 2014 19:07, Anatol Belski wrote: > Hi Dmitry, > > > On Mon, September 1, 2014 16:17, Dmitry Stogov wrote: > >> Hi Anatol, >> >> >> >> what do you mean? heap allocated structure? I think, it's not a good >> option :( >> >> I didn't have time to think about this yet. >> >> > I thought about creating an extended zend_string struct with an appended > offset member. Pointer to that structure could be injected into _zend_value > and were compatible with the normal zend_string and would be used only for > the offset case. But then, we could get rid of u2.str_offset and change > the meaning of the IS_STR_OFFSET related macros. > > That struct could be initialized the same way as any other in an opcode. > However I have yet to figure out where in the compiler this has to happen > (somewhere near the zend_compile_assign() i suppose). > > So, the approach described here isn't worky. While trying to implement it, I saw that it's not possible to isolate the exact case on compile time. A syntax like $s[0] = 's' can be related to too many things and on compilation time are abstract. Say $s = 'abc' is put somewhere in the script, but $s[0] = 'd' can be right the next statement or x lines later. This kind of things can be only catched on execution time. And, while working on that, I've realized that usage of zend_assign_to_string_offset() in the ASSIGN opcode is a dead case. So effectively, the only opcode where it has to be handled is ASSIGN_DIM. Also, I've rethought the solution - previously I was trying to integrate some overloaded struct to carry the correct offset. After I saw that's only one place where the actualy offset assignment can happen, I've changed the tactics. Now, reading the offset directly on execution time and passing to zend_assign_to_string_offset(). This one has no impact neither in perf nor in memory. No new structs or heap allocations, just a slightly modified flow. http://belski.net/phpz/64_str_offset_better.patch Please take a look. I'd suggest to give this last patch a try and would apply this WE if there's no objection. Regards anatol