Hello!
We've been working with storing some object metadata on instance variable assignments (i.e. the assigned object's class). Doing so in the "Stack VM" meant adding some code to certain primitives, we now find ourselves failing to extend this functionality to the Cog VM (StackToRegisterMappingCogit).
As a proof of concept, we decided to use non-inlined C versions of the methods we defined for the Stack VM in the cogged primitives. We tried defining a new trampoline (with 3 arguments and no return) for this and then generating calls to it from the cogged primitive generators, but to no avail.
Is this the way to go or is there an easier way to call a VM C function from a cogged primitive? Is there any documentation on how to define and use a new trampoline?
Thanks in advance! Leandro
-- Sent from: http://forum.world.st/Smalltalk-VM-Beginners-f3068605.html
Hi Leandro,
On Mon, Jun 10, 2019 at 10:08 AM lgvidal lgvidal@gmail.com wrote:
Hello!
We've been working with storing some object metadata on instance variable assignments (i.e. the assigned object's class). Doing so in the "Stack VM" meant adding some code to certain primitives, we now find ourselves failing to extend this functionality to the Cog VM (StackToRegisterMappingCogit).
As a proof of concept, we decided to use non-inlined C versions of the methods we defined for the Stack VM in the cogged primitives. We tried defining a new trampoline (with 3 arguments and no return) for this and then generating calls to it from the cogged primitive generators, but to no avail.
Have you looked at the delivery of the #attemptToAssign:withIndex: message used to report a read-only object modification error? his code works and has been in production in both the StackInterpreter and the Cogit for over a year now.
Browse references to VMBasicConstants' #IMMUTABILITY class var, e.g.
self systemNavigation browseAllCallsOn: (VMBasicConstants bindingOf: #IMMUTABILITY)
Is this the way to go or is there an easier way to call a VM C function from a cogged primitive?
This is the way to go. But it has to be done just so :-). Follow the scheme used for #attemptToAssign:withIndex: and you should do OK.
Is there any documentation on how to define and use a new trampoline?
No, only the examples in the system. Some errors should be straight-toward to fix; the various implementations of numTrampolines must compute a large enough trampoline table. Other errors, such as failure to provide a valid continuation on returning from the "send back" may be more difficult. I'm here to help.
Thanks in advance! Leandro
-- Sent from: http://forum.world.st/Smalltalk-VM-Beginners-f3068605.html _______________________________________________ VM-beginners mailing list VM-beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners
Hi Eliot,
Thank you very much for your input. We've been slowly making progress with this, currently trying to get a working compiled version of the VM to work (been using the simulator so far, apparently not as straightforward as running the mvm script).
We will likely pop here again in the future Thanks for your help, cheers!
-- Sent from: http://forum.world.st/Smalltalk-VM-Beginners-f3068605.html
Hi Eliot, I have been working with Leandro on this. We had looked the implementation of other trampolines and it seems to be working on the simulator but not on the real VM. Currently the VM is starting, and it loads the image correctly, but it fails on mouse move with the next error:
Cog JIT internal error. Too many abstract opcodes. Num opcodes heuristic is too optimistic.
We found that error is only throwed within StackToRegisterMappingCogit>>#compileAbstractInstructionsFrom:through:
Also, if we run the VM with the asserts we see things like:
opcodeIndex < numAbstractOpcodes 7022 opcodeIndex < numAbstractOpcodes 7041 opcodeIndex < numAbstractOpcodes 7062
Which are related with Cogit>>#gen:operand:operand:operand:
We have tried doing an empty trampoline with only a printf inside and the printf is being called. The trampoline is:
ceKeepInstanceVariableTypeInformationFor: anAssignedObject in: rcvr at: instVarIndex <api> self cCode: 'printf("hello");'.
Seems like we need to change the way the number of abstract opcodes is calculated, but we didn't found where to change it. Are we right? Any idea about it?
Federico
On Tue, Jul 2, 2019 at 1:05 PM lgvidal lgvidal@gmail.com wrote:
Hi Eliot,
Thank you very much for your input. We've been slowly making progress with this, currently trying to get a working compiled version of the VM to work (been using the simulator so far, apparently not as straightforward as running the mvm script).
We will likely pop here again in the future Thanks for your help, cheers!
-- Sent from: http://forum.world.st/Smalltalk-VM-Beginners-f3068605.html _______________________________________________ VM-beginners mailing list VM-beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners
vm-beginners@lists.squeakfoundation.org
-
Eliot Miranda -
Federico Grosso -
lgvidal