[Vm-dev] VMMaker : Inlining loop with MiscPrimitivesPlugin on
David T. Lewis
lewis at mail.msen.com
Fri Nov 6 03:47:15 UTC 2009
On Tue, Nov 03, 2009 at 02:06:36PM +0100, Nicolas Cellier wrote:
> 2009/11/3 David T. Lewis <lewis at mail.msen.com>:
> > On Tue, Nov 03, 2009 at 11:46:50AM +0100, arnaud Jean Baptiste wrote:
> >> the MiscPrimitivesPlugin loop when generating.
> >> the cause is :
> >> the primitives: #findSubstring:in:startingAt:matchTable:
> >> was change to the primitive that name is now:
> >> #findSubstringViaPrimitive:in:startingAt: matchTable:
> >> i can simply change the name in #translatedPrimitives
> >> (MiscPrimitivePlugin ) method but i am looking for long term solution.
> > Good question.
> > Pharo is doing this in ByteString:
> > findSubstring: key in: body startingAt: start matchTable: matchTable
> > ? ? ? ?key isWideString ifTrue: [^super findSubstring: key in: body startingAt: start matchTable: matchTable].
> > ? ? ? ?^self findSubstringViaPrimitive: key in: body startingAt: start matchTable: matchTable
> > I am not familiar with WideString usage, perhaps someone can comment as
> > to whether the the #findSubstringViaPrimitive:in:startingAt:matchTable: is
> > likely to be adopted in Squeak generally. If yes, then we should probably
> > change MiscPrimitivePlugin class>>translatedPrimitives to look for that
> > selector if present in the image. Or perhaps the check for WideString
> > belongs in the primitive itself?
> http://bugs.squeak.org/view.php?id=6366 has been solved differently in
> trunk and Pharo.
> Changes in Pharo are stamped with an anterior date and might come from
> another project (Sophie ?).
> I think the check for WideString belongs to primitive, and super call
> belongs to fallback code.
If I understand correctly:
- The fix from Mantis 6366, now in Squeak trunk, resolves the problem
- If Pharo adopts the Mantis 6366 fix, then no changes are required for VMMaker
Is that right?
More information about the Vm-dev