[Vm-dev] VMMaker small problem for pharo developper

[David T. Lewis]

On Thu, Mar 18, 2010 at 02:08:36PM +0100, Henrik Johansen wrote:
> 
> 
> On Mar 18, 2010, at 1:26 10PM, Jean Baptiste Arnaud wrote:
> 
> > 
> > Then what is the solution ? We could have a Pharo immutability bit VM, but that it can be better to share with squeak. (which should be easy, if these differences are fixed ).
> 
> I agree.
> 
> One solution for the case I mentioned is to not hardcode where the primitives in such cases as MiscPrimitivePlugin are defined, but instead discover them in the image VMMaker is loaded into.
> Thus you remove the link between VMMaker, and the image it's loaded into defining primitives in certain places, so the same VMMaker can work for both Squeak and Pharo as described.
> 
> F.ex. like this:
> 
> MiscPrimitivePlugin class>>translatedPrimitives
> oc := OrderedCollection new.
> CompiledMethod allInstancesDo: [:each | 
> 	(each pragmaAt: #primitive:module:) ifNotNil: [:prag | 
> 		((prag  argumentAt: 2) = 'MiscPrimitivePlugin'  and: [each literals includes: #var:declareC:]) 
> 			ifTrue: [ oc add: (Array with: each methodClass name with: each selector)]]].
> ^oc asArray
> 
> This assumes the method defining the primitive will include the primitive pragma, which should always be the case.
> The "each literals includes: #var:declareC:" is a bit of a hack for disambiguating the CompiledMethod defining the primitive from other callers.
> AFAIK, hints like that are required if the method is to be translated, and you are unlikely to find it in other callers. If anyone has a better idea, I'd appreciate it.

Henry,

Thank you for opening a mantis report on this at
  http://bugs.squeak.org/view.php?id=7479

I think your pragma idea may work, but IMO this is getting too
complicated.  Perhaps the change in Pharo was done without realizing
the problem it would cause for C code generation. So that means
that the primitive is already too clever - it is easy for someone to
look at the Smalltalk method and not realize that it is designed to
be translated to C. I am afraid that adding pragmas will only make
it harder for people to understand how this works.

So my opinion FWIW is that if we really need different methods in
the Squeak and Pharo images, then maybe it is time to reimplement
this primitive as a normal primitive, rather than using the magic
of MiscPrimitivePlugin translating methods directly from the image.

But to be honest I am not convinced that the Pharo method really needs
to be renamed to #findSubstringViaPrimitive:in:startingAt:matchTable:.
Perhaps there is some other way to accomplish this refactoring without
causing compatibility problems?

Dave