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

[David T. Lewis]

I already fixed the type inference issue, so that issue is resolved:

  Name: VMMaker.oscog-dtl.3004
  Author: dtl
  Time: 27 July 2021, 7:04:41.67977 pm
  Update sizeOfIntegralCType: and related methods and tests to recognize #unsigned
  and #uint_32 declarations as 32 bit integer.
  Supports VectorEnginePlugin code generation.

I found one more issue that I had not noticed before. I've been building
the plugin with debugging enabled (./build.debug/mvm as opposed to ./build/mvm)
but I see now that the plugin does not work when compiled "normally", so
I expect there is some compiler -O setting that needs to be adjusted.

More to follow,
Dave


On Wed, Jul 28, 2021 at 12:21:41PM -0300, Juan Vuletich via Cuis-dev wrote:
> 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
> >
> 
> 
> -- 
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev