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

Juan Vuletich juan at jvuletich.org
Wed Jul 28 08:21:41 PDT 2021

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

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

More information about the Cuis-dev mailing list