Hi Ben, Hi All,
On Oct 30, 2018, at 7:34 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Ben,
On Oct 30, 2018, at 6:26 AM, Ben Coman btc@openinworld.com wrote:
On Tue, 30 Oct 2018 at 20:22, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Ben,
On Oct 30, 2018, at 4:57 AM, Ben Coman btc@openinworld.com wrote:
I'm sure this was explained somewhere before (even recently), but I forget, and can't find anything in my usual search places.
On Tue, 30 Oct 2018 at 09:02, commits@source.squeak.org wrote:
Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2479.mcz
==================== Summary ====================
Name: VMMaker.oscog-eem.2479 Author: eem Time: 29 October 2018, 6:00:57.748695 pm UUID: b191888c-6777-483b-82b4-121103743ebf Ancestors: VMMaker.oscog-eem.2478
Plugins: Fix slip in primitiveDirectoryDelimitor. Eliminate cCode:inSmalltalk:'s from the B3DAcceleratorPlugin
=============== Diff against VMMaker.oscog-eem.2478 ===============
<snip> Item was changed: ----- Method: B3DAcceleratorPlugin>>primitiveAllocateTexture (in category 'primitives-textures') ----- primitiveAllocateTexture | h w d result renderer | <export: true> interpreterProxy methodArgumentCount = 4 ifFalse:[^interpreterProxy primitiveFail]. h := interpreterProxy stackIntegerValue: 0. w := interpreterProxy stackIntegerValue: 1. d := interpreterProxy stackIntegerValue: 2. renderer := interpreterProxy stackIntegerValue: 3. interpreterProxy failed ifTrue:[^nil]. + result := self b3dxAllocateTexture: renderer _: w _: h _: d. - result := self cCode:'b3dxAllocateTexture(renderer, w, h, d)' inSmalltalk:[-1]. result = -1 ifTrue:[^interpreterProxy primitiveFail]. interpreterProxy pop: 5. "args+rcvr" ^interpreterProxy pushInteger: result.!
What is the mechanism that allows cCode:inSmalltalk:'s to be replaced like above? I half expected "b3dxAllocateTexture:_:_:_:" to be newly defined somewhere else in that commit.
Those implementations can come later. Right now the plugin doesn’t simulate anyway. You’re right I could have written them then and there, but I would rather do real o es than simple failing stubs. If I find that I can’t simulate without stubs I’ll add them. Feel free to provide them if you’re motivated. I should have just fixed the digitCompare: issue but got carried away...
I'm still missing something basic, but guessing... the "inSmalltalk:" part is what is performed by the simulator?
I’m sorry; yes. Given self cCode: stringOrBlock inSmalltalk: block the C translator will either emit stringOrBlock verbatim if stringOrBlock is a string, or emit the translation of stringOrBlock’s statements if it is a block. The simulator simply evaluates block. And the value of the expression is, effectively, the value of either block.
and the "cCode:" is generated into a C-code-call that expects that function linked in from a library?
More accurately stringOrBlock is arbitrary code. Look for uses in BirBltSimulation and you’ll see the code for invoking the fast bitblt code for the Raspberry Pi. This assigns parameters for a bitblt invocation to a struct. One can define a struct in Smalltalk (VMStructType ? an approach I take for Cog method headers, stack pages, spur memory segments, etc) but Tim took the short cut of merely writing the verbatim C.
One stereotypical use was to write the invocation of some platform support function and have the inSmalltalk: either simulate or answer a default value, and sometimes to reference variables used in the call but unused elsewhere, to avoid Smalltalk compiler earnings. This is what we see here in the B3DAcceleratorPlugin. But using a default value precludes simulation, and the code is ugly. So I’ve started replacing as many cCode:inSmalltalk:’s with a message send where stringOrBlock is simply a call. This is dependent on _: keyword support and the <doNotGenerate> pragma to instruct Slang not to generate the simulator implementation. I added <doNotGenerate> several years ago; I added _: support a few weeks ago.
and now there is no simulation and "b3dxAllocateTexture:_:_:_:" is generated to C-code-call?
That would generate a call of b3dxAllocateTexture with the given arguments.
So is there a mechanism that any unknown message (i.e. "b3dxAllocateTexture:_:_:_:") is generated to a C-code-call?
Yes. Look for VMMaker.oscog-eem.2440 and VMMaker.oscog-eem.2452. And in general one can use self foo: expr bar: rpxe to generate a call of foobar. I simply added stripping out of _:, which means not having to split a call across several keywords; much more readable.
It might be useful to capture this “documentation” and the documentation elsewhere (eg on the Squeak wiki) and include it in help in the package. Anyone who has energy for this is very welcome to help.
cheers -ben