[Cuis-dev] Patch for VectorEnginePlugin code generation on oscog

[Juan Vuletich]

Hi Dave,

This is great! The fix is now at GitHub.

When I made one primitive function call another, I thought "maybe this 
can't be done". I tried it (in Cuis VMMaker) and it worked. I didn't 
realize it could break VMMaker.oscog.

If there is any way I can help with the oscog type inference problem, 
please let me know.

Thanks a lot!

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich


On 7/27/2021 7:15 PM, David T. Lewis via Cuis-dev wrote:
> Hi Juan,
>
> Attached is a patch to VectorEnginePlugin that allows the C code to be
> generated from VMMaker.oscog for opensmalltalk-vm.
>
> Background: The C generated code for VectorEnginePlugin from Cuis or Squeak
> VMMaker compiles and runs without issue in opensmalltalk VM. However, if
> the C code is generated from VMMaker.oscog, the plugin will fail at runtime
> with an unresolved symbol.
>
> Cause: The slang inliner in VMMaker.oscog is failing to inline newTrajectoryFragment,
> which is therefore referenced as C function newTrajectoryFragment() in various
> places in the plugin code. The method itself is generated as a primitive with
> different name, so primNewTrajectoryFragment() is generated instead. This
> results in undefined symbol references at runtime.
>
> The fix: Extract the (trivial) body of the primitive into a separate method.
> This allows the inliner to work on VMMaker.oscog.
>
> Note, there is another issue with the type inferencer in oscog code generation
> that I am looking at, but that is a separate issue.
>
> Dave
>