Hi, Support for primitive 169 for Object>>#~~ has been in the VM for a while. The default implementation in Squeak 5 uses this primitive for example. I've just added today (VMMaker commit 2003) support for inlined #~~ like #== (including JIT support, branch pipelining, etc.). If one puts #~~ in the specialObjectsArray at the location of #blockCopy:, the bytecode compiler generates the special send bytecode for #~~ leading to improved performance and consistency between #== and #~~. With today's update, the VM supports 3 inlined operations without any type checks: #==, #~~ and #class. It is possible to disable such optimisations in the bytecode compiler (In Pharo #class inlining is disabled there for example). Eliot would like to add support to disable these operations at VM level as a VM command line parameter too, and we may do it in the future. Now this is for the VM support. It's up to the Pharo/Squeak/other community to decide what behavior they want in their runtime for these 3 selectors. In my opinion, I believe that #~~ should be consistent with #==, hence they should be both inlined or both sends to primitives. I don't like the current situation in Pharo nor in Squeak. Now when we look for solutions, we see that one of #== and #~~ needs to be a primitive (it's essential), hence it makes sense to have both Object>>#== and Object>>#~~ as primitives (with the primitive pragma in the method body). The inlining of #== and #~~ is arguable and I let the community decide what they believe is best for their runtime, though I would rather have the same behavior for both selectors. Cheers On Wed, Nov 23, 2016 at 2:39 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi
It is been a while... So, do we want to replace ~~ with a primitive? :)
Cheers Alex
-- View this message in context: http://forum.world.st/About- and-tp3898409p4924391.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.