Nabble - Squeak - VM Dev

Fwd: vm-dev moving to lists.squeakfoundation.org

2006-07-20T03:01:00Z

Forwarded on behalf of Marcus The List Admin:

> From: Marcus Denker <denker@...>
> Date: 19. Juli 2006 23:11:31 GMT+02:00
>
> Hi,
>
> The list "vm-dev" is moving to Mailman.
>
> new adress: vm-dev@...
>
> Please subscribe to the new list:
> http://lists.squeakfoundation.org/mailman/listinfo/vm-dev
>
> Existing substriptions are *not* moved over, you need to re-subsribe!
> (The archives have been moved over).
>
> Posting to the old discuss list will be possible till tommorow,
> then it will be
> de-activated.
>
> Marcus
>
>

One-click plugin development

2006-07-10T04:34:19Z

I found myself doing this a gazillion times over the last days: click
the VMMaker's "generate plugin" button, switch to XCode, invoke the
plugin build, switch back to Squeak, unload the plugin to test the
new one.

No more.

A few lines of code automate all of this:

VMMaker>>generateExternalPlugins
...
externalPlugins size = 1 ifTrue: [
| result |
logger show: 'XCode: building ', externalPlugins first, ' ... '.
result := Applescript doIt: 'tell application "XCode" to build'.
logger show: result; cr.
(result beginsWith: '"Build succeeded')
ifTrue: [Smalltalk unloadModule: externalPlugins first]
ifFalse: [Applescript doIt: 'tell application "XCode" to activate']].

Now I just click "generate plugin" and debug on. Life is bright
again. Except for the occasional crash, of course :)

- Bert -

Re: Mac build setup?

2006-07-07T17:49:28Z

Thanks John. Just what I was looking for.

Cheers,
- Andreas

John M McIntosh wrote:

> Download the SVN tree, there is a readme document in the mac document
> folder that explains how to build
> we try to keep it current, so start with that and let me know if problem.
>
>
> final test of course is if bytecode/send rate is same as published vm
>
> On 7-Jul-06, at 3:41 PM, Andreas Raab wrote:
>
>> Hi John -
>>
>> I need to do a bit of work with a custom Mac VM and I was wondering
>> what setup you use these days to build VMs. Is there any document
>> somewhere that describes your setup, steps to take etc. to build a Mac
>> VM?
>>
>> Thanks,
>> - Andreas
>
> --
> ===========================================================================
> John M. McIntosh <johnmci@...> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> ===========================================================================
>
>

Re: Mac build setup?

2006-07-07T17:20:10Z

Download the SVN tree, there is a readme document in the mac document
folder that explains how to build
we try to keep it current, so start with that and let me know if
problem.

final test of course is if bytecode/send rate is same as published vm

On 7-Jul-06, at 3:41 PM, Andreas Raab wrote:

> Hi John -
>
> I need to do a bit of work with a custom Mac VM and I was wondering
> what setup you use these days to build VMs. Is there any document
> somewhere that describes your setup, steps to take etc. to build a
> Mac VM?
>
> Thanks,
> - Andreas

--
========================================================================
===
John M. McIntosh <johnmci@...> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===

Mac build setup?

2006-07-07T16:41:57Z

Hi John -

I need to do a bit of work with a custom Mac VM and I was wondering what
setup you use these days to build VMs. Is there any document somewhere
that describes your setup, steps to take etc. to build a Mac VM?

Thanks,
- Andreas

Re: [FIX] lockSurfaces

2006-07-07T02:09:54Z

Yup. Small but important fix - if this ever hits you you're dead in the
water. Thanks for finding it!

Cheers,
- Andreas

Bert Freudenberg wrote:

> There is a wrong condition in an almost never-taken branch of
> BitBltSimulation>>lockSurfaces (when src=dst):
>
> isWarping ifFalse:[
> "When warping we always need the entire surface for
> the source"
> sourceBits _ self cCode:'fn(sourceHandle,
> &sourcePitch, 0,0, sourceWidth, sourceHeight)'.
> ] ifTrue:[
> "Otherwise use overlapping area"
> l _ sx min: dx. r _ (sx max: dx) + bbW.
> t _ sy min: dy. b _ (sy max: sy) + bbH.
> sourceBits _ self cCode:'fn(sourceHandle,
> &sourcePitch, l, t, r-l, b-t)'.
> ].
>
> As the comments indicate, the condition is reversed. Please include
> attached fix in VMMaker.
>
> - Bert -
>
>

[FIX] lockSurfaces

2006-07-07T02:08:26Z

There is a wrong condition in an almost never-taken branch of
BitBltSimulation>>lockSurfaces (when src=dst):

isWarping ifFalse:[
"When warping we always need the entire surface
for the source"
sourceBits _ self cCode:'fn(sourceHandle,
&sourcePitch, 0,0, sourceWidth, sourceHeight)'.
] ifTrue:[
"Otherwise use overlapping area"
l _ sx min: dx. r _ (sx max: dx) + bbW.
t _ sy min: dy. b _ (sy max: sy) + bbH.
sourceBits _ self cCode:'fn(sourceHandle,
&sourcePitch, l, t, r-l, b-t)'.
].

As the comments indicate, the condition is reversed. Please include
attached fix in VMMaker.

- Bert -

bltBltLockFix-bf.1.cs.gz (2K) Download Attachment

Re: Re: newbie trouble building Squeak VM on Mac

2006-07-03T14:08:37Z

Hi Ian,

On 7/3/06, Ian Piumarta <piumarta@...> wrote:
> The usual reason for confusion about gl.h availability is that the
> build cannot find the xmkmf program. If you do have the X11 SDK
> installed then make absolutely sure /usr/X11R6/bin is in your PATH
> before you try to build the VM.

thank you very much! Indeed, the X11 bin directory is not in the path,
so I'll try it once more with that. (Even though it works fine with
the --without-x option...)

Best,

Michael

Re: newbie trouble building Squeak VM on Mac

2006-07-03T14:05:02Z

Hi Michael,

> /Users/haupt/squeakvm/squeak-svn/platforms/unix/plugins/
> B3DAcceleratorPlugin/sqUnixOpenGL.h:26:7:
> error: #error *** cannot find gl.h
>
> Huh. Apparently the configure script thought there was OpenGL on the
> machine, didn't it? Anyway, where / how can I obtain that file

If you're building vm-display-X11 then gl.h is /usr/X11R6/include/GL/
gl.h. It comes with the X11 SDK.

For vm-display-Quartz the file is part of the OpenGL framework: /Sys/
Lib/Frameworks/OpenGL.framework/Headers/gl.h. It comes with Mac OS X.

The usual reason for confusion about gl.h availability is that the
build cannot find the xmkmf program. If you do have the X11 SDK
installed then make absolutely sure /usr/X11R6/bin is in your PATH
before you try to build the VM.

Cheers,
Ian

Re: newbie trouble building Squeak VM on Mac

2006-07-03T14:01:43Z

Hi again,

On 7/3/06, Michael Haupt <mhaupt@...> wrote:
> I have checked out the latest VM sources from svn today, run the
> configure script (for the unix platform - I have a G4 PowerBook
> running Mac OS X 10.4.7), and issued "make Squeak.app".
>
> Eventually, the build stops with an error:
>
> /Users/haupt/squeakvm/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.h:26:7:
> error: #error *** cannot find gl.h

now that was a stupid question. :-)

Running configure with the --without-x option did the trick. Quite obviously so.

Best,

Michael

newbie trouble building Squeak VM on Mac

2006-07-03T10:24:09Z

Hi,

it's my first attempt ever to actually build a Squeak VM, hence the
crosspost to both the beginners' and VM dev lists.

I have checked out the latest VM sources from svn today, run the
configure script (for the unix platform - I have a G4 PowerBook
running Mac OS X 10.4.7), and issued "make Squeak.app".

Eventually, the build stops with an error:

/Users/haupt/squeakvm/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.h:26:7:
error: #error *** cannot find gl.h

Huh. Apparently the configure script thought there was OpenGL on the
machine, didn't it? Anyway, where / how can I obtain that file or
exclude OpenGL support?

Thanks in advance,

Michael

Re: InterpreterSimulator and friends

2006-06-24T23:04:34Z

Thanks for the quick reply!

It might be useful adding the following information to SqueakVM.org:

- How to find the Squeak-VM mailing list.

- Where the code is and how to get it (i.e. svn://squeakvm.org/... and
SqueakMap).

- How to contribute changes.

Cheers,
Mikevdg.

tim Rowledge wrote:

>
> On 23-Jun-06, at 8:49 PM, Michael van der Gulik wrote:
>
>> Hi all.
>>
>> Where is the latest stable version of VMMaker? Is it
>> VMMaker-3.8b6.mcz from SqueakMap
>
> Yes
>
>> , or VMMaker-tpr-5.mcz (which seems old) from SqueakSource.com?
>
> No - after a few attempts with squeaksource a long time ago I gave
> up; not particularly because of any fault but it simply didn't suit
> my working habits.
>
>> Or somewhere else?
>
> Nope. SM is it.
>
>>
>> I see that squeakvm.org has an SVN server, but where do you keep
>> your Monticello files?
>
> When the swiki is running (I can't access it right now) search for
> VMMaker and you should find all the documentation you need. If you
> don't, let us know what you think it missing and it has a chance of
> getting improved!
> I don't keep all the MC files publically accessible because
> intermediate states are normally not usable. Releases on SM are known
> to have built working VMs on at least two OSs.
>
>>
>> I've got a bug, probably in my code but maybe in the VM, involving
>> becomeForward:copyHash:. The primitive is failing for no apparant
>> reason. I plan to try running this code in the InterpreterSimulator
>> to find exactly why primitive 239 is failing.
>
> The immediate things I can think of involve some checks early in the
> prim that protect you against catastrophe.
> Comment from ObjectMemory>prepareForwardingTableForBecoming: array1
> with: array2 twoWay: twoWayFlag
> "Important note on multiple references to same object - since
> the preparation of
> fwdBlocks is NOT idempotent we get VM crashes if the same object
> is referenced more
> than once in such a way as to require multiple fwdBlocks.
> oop1 forwardBecome: oop1 is ok since only a single fwdBlock is
> needed.
> oop1 become: oop1 would fail because the second fwdBlock woudl
> not have the actual object
> header but rather the mutated ref to the first fwdBlock.
> Further problems can arise with an array1 or array2 that refer
> multiply to the same
> object. This would notbe expected input for programmer writen
> code but might arise from
> automatic usage such as in ImageSegment loading.
> To avoid the simple and rather common case of oop1 become*: oop1,
> we skip such pairs
> and simply avoid making fwdBlocks - it is redundant anyway"
>
>>
>> Currently I've tried both VMMaker-tpr.58.mcz and VMMaker-3.8b6.mcz,
>> but the InterpreterSimulator doesn't want to work.
>
>
> I make no guarantee on the state of InterpreterSimulator. I was under
> the impression that it was functional in the current version, mostly
> because of a lot of work Craig did to support his Spoon project. I
> simply don't have enough spare time to do all the work and the
> simulator is one area I have to leave for others to worry about.
>
>> I get a DNU, which I fixed, but then I get another DNU, which I
>> fixed, but then I got another, so I threw the whole thing away in
>> disgust. I have a bog standard 32-bit AMD-based PC running Ubuntu.
>
> Sometimes you just have to keep bashing those balrogs.
>
> tim
> --
> tim Rowledge; tim@...; http://www.rowledge.org/tim
> Press [ESC] to detonate or any other key to explode.
>
>
>
>
>

Re: ObjectiveCPlugin, VMMaker usage

2006-06-24T21:02:31Z

OK, following Goran's instructions at http://goran.krampe.se/blog, I
can now build a VM. But when I add a plugin (ObjC or GTK) I get
strange compile errors...

for the ObjC plugin:

In file included from Squeak-3.9-7/build/config.h:184,
from Squeak-3.9-7/platforms/Cross/vm/sqMemoryAccess.h:19,
from Squeak-3.9-7/platforms/Cross/vm/sqVirtualMachine.h:15,
from
Squeak-3.9-7/platforms/unix/plugins/ObjectiveCPlugin/sqUnixObjC.m:2:
Squeak-3.9-7/platforms/unix/vm/glibc.h:6: error: syntax error before 'c'
Squeak-3.9-7/platforms/unix/vm/glibc.h:6: error: syntax error before '&' token
Squeak-3.9-7/platforms/unix/vm/glibc.h:7: error: syntax error before 'c'
[...]

is it a compiler problem, or some preprocessor stuff that the objc
compiler doesn't like ?

for the GtkPlugin:

Squeak-3.9-7/platforms/unix/plugins/GtkPlugin/sqUnixGtkPrims.c: In
function 'GenericCallback':
Squeak-3.9-7/platforms/unix/plugins/GtkPlugin/sqUnixGtkPrims.c:123:
error: 'struct VirtualMachine' has no member named 'callbackEnter'
Squeak-3.9-7/platforms/unix/plugins/GtkPlugin/sqUnixGtkPrims.c: In
function 'gReturnFromCallback':
Squeak-3.9-7/platforms/unix/plugins/GtkPlugin/sqUnixGtkPrims.c:149:
error: 'struct VirtualMachine' has no member named 'callbackLeave'

This one is really funny because I grepped the sources (both 3.9-7 and
svn) and these identifiers appear nowhere else...

I'm on Linux x86, using GNUstep for the Foundation libs. Any idea?

--
Damien Pollet
type less, do more

InterpreterSimulator and friends

2006-06-23T21:49:34Z

Hi all.

Where is the latest stable version of VMMaker? Is it VMMaker-3.8b6.mcz
from SqueakMap, or VMMaker-tpr-5.mcz (which seems old) from
SqueakSource.com? Or somewhere else?

I see that squeakvm.org has an SVN server, but where do you keep your
Monticello files?

I've got a bug, probably in my code but maybe in the VM, involving
becomeForward:copyHash:. The primitive is failing for no apparant
reason. I plan to try running this code in the InterpreterSimulator to
find exactly why primitive 239 is failing.

Currently I've tried both VMMaker-tpr.58.mcz and VMMaker-3.8b6.mcz, but
the InterpreterSimulator doesn't want to work. I get a DNU, which I
fixed, but then I get another DNU, which I fixed, but then I got
another, so I threw the whole thing away in disgust. I have a bog
standard 32-bit AMD-based PC running Ubuntu.

Mikevdg.

ObjectiveCPlugin, VMMaker usage

2006-06-16T16:53:23Z

Hi,

tonight I've been trying without success to build Alain's ObjectiveCPlugin:
http://lists.apple.com/archives/objc-language/2004/Apr/msg00002.html
I'm using the latest tarball of the VM source, VMMaker from SqueakMap,
and a 3.9 7033 image.

I got VMM to generate an ObjectiveCPlugin.c file, but the build system
doesn't seem to see it, even after running make in unix/config,
re-configuring, and RTFMing:
http://squeakvm.org/unix/devel.html#html/devel.m4.3.1
http://minnow.cc.gatech.edu/squeak/VMMaker

That's my first attempt at this kind of stunt, and I would welcome
pointers and suggestions :-)

--
Damien Pollet
type less, do more

Re: VM (callback+variables) changes

2006-06-13T23:11:16Z

Hi Rob -

Rob Gayvert wrote:
> My callback usage is intense but of limited variety, so the callback ids
> are not much of a burden. Without an id, there would be no way to check
> whether the callbacks were being exited in the proper order. For some
> cases that might not be important, but it might also result in some
> nasty bugs. How about making it optional by passing a null value?

Well, in this case let's just leave it the way it is. There is nothing
worse than somebody else (who is not using the interface) screwing up
your callback return ;-)

> On the process management question, I'm afraid I don't understand this
> area well enough. Is your concern as aesthetic one, or are there
> performance or correctness issues with your current implementation?

Well, I just kinda dislike the idea of an array holding onto a bunch of
processes without a way about reflecting about them. At some point this
is going to get us into trouble when somebody wonders why the heck this
process doesn't get garbage collected. It would be better if there were
an explicit reference to it somewhere. So I guess it ain't critical (and
requires some image-side support too).

Cheers,
- Andreas

Re: VM (callback+variables) changes

2006-06-13T13:29:52Z

My callback usage is intense but of limited variety, so the callback ids
are not much of a burden. Without an id, there would be no way to check
whether the callbacks were being exited in the proper order. For some
cases that might not be important, but it might also result in some
nasty bugs. How about making it optional by passing a null value?

On the process management question, I'm afraid I don't understand this
area well enough. Is your concern as aesthetic one, or are there
performance or correctness issues with your current implementation?

.. Rob

Andreas Raab wrote:

> Hi Rob -
>
> Good to hear it works. There are two things that bothers me slightly and
> I'd like to get some feedback from someone who's been in that area
> before: First, the callback identifier. While it seems a good safeguard
> at first it gets into ones way pretty quickly (like in the example
> plugin where the absence of callback-id management makes it impossible
> to have more than one callback). So... do you think it's worthwhile to
> keep it and force people to go through the hoops of maintaining it?
>
> Second, I'm somewhat unhappy about the management of the suspended
> processs. I am wondering if we shouldn't use a semaphore in the
> splObjects for this purpose and link/unlink properly. This has the
> disadvantage that some image-side changes are required but it might be
> worth it for better house-keeping.
>
> Comments welcome!
> - Andreas
>
> Rob Gayvert wrote:
>
>> Andreas,
>>
>> This looks great. I tried this out with a fresh 3.9-7033 image and
>> latest Win32 VM source, and your example worked as advertised. It also
>> works fine as a replacement for my wxSqueak setjmp/longjmp calls, and
>> removes the need for an extra semaphore on the calling process. Thanks!
>>
>> .. Rob
>>
>>
>> Andreas Raab wrote:
>>
>>> Hi Folks -
>>>
>>> Attached my proposed changes for both, the variable tracking as well
>>> as the callback support. I'll respond in the individual threads about
>>> more specific issues; let's leave this one to discuss the more
>>> "mechanical" issues if there are any. Included files:
>>>
>>> - ExtraGCRoots.cs: The change set for tracking variables in plugins
>>> - Callbacks.cs: The change set for VM callback support
>>> - ExampleCallbacks.cs: An example plugin making use of both of the
>>> above features
>>> - sqVirtualMachine[.h|.c]: The (updated) VM proxy
>>>
>>> If you install all of the above and build a complete VM you should be
>>> able to execute the ExampleCallbackPlugin's exampleCallback and
>>> successfully compute 3+4 using a callback.
>>>
>>> Let me know if you have any problems.
>>>
>>> Cheers,
>>> - Andreas
>>>
>>>
>>
>>
>>
>

Re: VM (callback+variables) changes

2006-06-12T14:36:57Z

Hi Rob -

Good to hear it works. There are two things that bothers me slightly and
I'd like to get some feedback from someone who's been in that area
before: First, the callback identifier. While it seems a good safeguard
at first it gets into ones way pretty quickly (like in the example
plugin where the absence of callback-id management makes it impossible
to have more than one callback). So... do you think it's worthwhile to
keep it and force people to go through the hoops of maintaining it?

Second, I'm somewhat unhappy about the management of the suspended
processs. I am wondering if we shouldn't use a semaphore in the
splObjects for this purpose and link/unlink properly. This has the
disadvantage that some image-side changes are required but it might be
worth it for better house-keeping.

Comments welcome!
- Andreas

Rob Gayvert wrote:

> Andreas,
>
> This looks great. I tried this out with a fresh 3.9-7033 image and
> latest Win32 VM source, and your example worked as advertised. It also
> works fine as a replacement for my wxSqueak setjmp/longjmp calls, and
> removes the need for an extra semaphore on the calling process. Thanks!
>
> .. Rob
>
>
> Andreas Raab wrote:
>> Hi Folks -
>>
>> Attached my proposed changes for both, the variable tracking as well
>> as the callback support. I'll respond in the individual threads about
>> more specific issues; let's leave this one to discuss the more
>> "mechanical" issues if there are any. Included files:
>>
>> - ExtraGCRoots.cs: The change set for tracking variables in plugins
>> - Callbacks.cs: The change set for VM callback support
>> - ExampleCallbacks.cs: An example plugin making use of both of the
>> above features
>> - sqVirtualMachine[.h|.c]: The (updated) VM proxy
>>
>> If you install all of the above and build a complete VM you should be
>> able to execute the ExampleCallbackPlugin's exampleCallback and
>> successfully compute 3+4 using a callback.
>>
>> Let me know if you have any problems.
>>
>> Cheers,
>> - Andreas
>>
>>
>
>
>

Re: VM (callback+variables) changes

2006-06-12T07:14:30Z

Andreas,

This looks great. I tried this out with a fresh 3.9-7033 image and
latest Win32 VM source, and your example worked as advertised. It also
works fine as a replacement for my wxSqueak setjmp/longjmp calls, and
removes the need for an extra semaphore on the calling process. Thanks!

.. Rob

Andreas Raab wrote:

> Hi Folks -
>
> Attached my proposed changes for both, the variable tracking as well as
> the callback support. I'll respond in the individual threads about more
> specific issues; let's leave this one to discuss the more "mechanical"
> issues if there are any. Included files:
>
> - ExtraGCRoots.cs: The change set for tracking variables in plugins
> - Callbacks.cs: The change set for VM callback support
> - ExampleCallbacks.cs: An example plugin making use of both of the above
> features
> - sqVirtualMachine[.h|.c]: The (updated) VM proxy
>
> If you install all of the above and build a complete VM you should be
> able to execute the ExampleCallbackPlugin's exampleCallback and
> successfully compute 3+4 using a callback.
>
> Let me know if you have any problems.
>
> Cheers,
> - Andreas
>
>

Re: Squeak port to Amiga progress 6-10

2006-06-10T21:48:24Z

On Jun 10, 2006, at 6:44 PM, Tim Johnson wrote:

> A sticking point right now is noticeable on the current screenshot.
> After the image has loaded with its initial project setup, any
> newly-opened windows (browser, transcript, or zooming any of the Play
> With Me's) causes two window gadgets to appear, but no actual window.
> Nicely, PopUpMenus work great. I am at a loss.

Whoops! Fixed this... changed a few #defines in sqConfig.h and deleted
old object files... *blush*

> Also I have not yet dug deeply into the file code. I have a feeling
> my directory delineators will not work, as the Amiga uses a
> combination of :'s and /'s; i.e. "DH0:Development/Squeak/SqueakVM".
> Why this would keep a browser from opening, I am not sure.

Thanks to a tip from Mr. Rowledge, I'll be able to whip up some file
directory support...

Cheers,
Tim

Squeak port to Amiga progress 6-10

2006-06-10T17:44:10Z

Hello Everyone,

As of today I have speedy bitmap display working correctly, through the
use of the Amiga system's native WriteChunkyPixels() function and
built-in clipping functionality of the layers library. Mouse clicking
works and windows can be moved around successfully, scroll-bars scroll,
text can be selected.

http://metaphorse.com/amiga/squeak/

Alas, the colors are wrong, as I have not yet done any color mapping.
I also seem to be stuck to 8-bit depths with this 2.3 VM, which is
strange, but may make my life easier right now. (I believe that the
Amiga's graphics system will automatically handle writing different
bit-depths to any depth screen, which would be nice. I am crossing my
fingers. I have been able to use this 8-bit display on 8-bit and
15-bit displays with no changed code).

A sticking point right now is noticeable on the current screenshot.
After the image has loaded with its initial project setup, any
newly-opened windows (browser, transcript, or zooming any of the Play
With Me's) causes two window gadgets to appear, but no actual window.
Nicely, PopUpMenus work great. I am at a loss.

Also I have not yet dug deeply into the file code. I have a feeling my
directory delineators will not work, as the Amiga uses a combination of
:'s and /'s; i.e. "DH0:Development/Squeak/SqueakVM". Why this would
keep a browser from opening, I am not sure.

Thanks everyone for your help so far. This is turning out to be quite
the adventure.

Cheers,
Tim J.

Re: [Fwd: Re: Keeping oops across primitives]

2006-06-09T16:29:18Z

Tony Garnock-Jones wrote:
> Andreas Raab wrote:
>> Actually, this is an interesting thought. I have the need for managing a
>> dynamic array of roots but this could be handled just as easily by
>> tracking a variable pointing to a Squeak array.
>
> A variable in C is more-or-less a one-place array, so perhaps supporting
> arrays is the simpler option?

Turns out not. The code is much simpler supporting just individual oop
locations (variables) so I decided to go with the following interface:

sqInt oopVar; /* declare a global that we wish to track */

{
...
oopVar = vm->nilObject(); /* don't forget to initialize it !!! */
vm->addGCRoot(&oopVar); /* update it */
...
}

and to undo that

{
...
vm->removeGCRoot(&oopVar);
...
}

Cheers,
- Andreas

Re: Callbacks, simplified.

2006-06-09T16:27:01Z

Hi Rob -

Rob Gayvert wrote:

> Andreas Raab wrote:
>> > Do you have any thoughts on how this could be handled better?
>>
>> How about we just suspend the currently active process when we
>> re-enter the interpreter? As long as the callback is synchronous (it
>> better be) this should work just fine, right?
>
> Yes, that should do the trick. I tried doing something like this awhile
> back, but couldn't get it to work reliably. I suspect the problem was
> that the process oop might move during a callback, in which case trying
> to resume it would cause a crash. It sounds like your other changes to
> keep oops across primitives would solve this.

Yes, although (if you look at the changes) I decided to keep this
internal in the VM because it is also necessary to ensure proper
resumption upon callback return (otherwise the return value will be
inaccurate). So the ultimate solution goes like this:

Upon entering the callback, suspend the active process forcefully. Upon
returning from the callback resume the active process forcefully(!) so
that the "returning primitive" (e.g., the primitive which invoked the
callback) can set the proper return value.

As far as I am aware that solves the trick completely (check out the
code) at the cost of requiring that callbacks are only entered during
the execution of primitives (meaning that the interpreter's state is
externalized).

Cheers,
- Andreas

VM (callback+variables) changes

2006-06-09T16:22:39Z

Hi Folks -

Attached my proposed changes for both, the variable tracking as well as
the callback support. I'll respond in the individual threads about more
specific issues; let's leave this one to discuss the more "mechanical"
issues if there are any. Included files:

- ExtraGCRoots.cs: The change set for tracking variables in plugins
- Callbacks.cs: The change set for VM callback support
- ExampleCallbacks.cs: An example plugin making use of both of the above
features
- sqVirtualMachine[.h|.c]: The (updated) VM proxy

If you install all of the above and build a complete VM you should be
able to execute the ExampleCallbackPlugin's exampleCallback and
successfully compute 3+4 using a callback.

Let me know if you have any problems.

Cheers,
- Andreas

#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include "sqVirtualMachine.h"

/*** Function prototypes ***/

/* InterpreterProxy methodsFor: 'stack access' */
sqInt pop(sqInt nItems);
sqInt popthenPush(sqInt nItems, sqInt oop);
sqInt push(sqInt object);
sqInt pushBool(sqInt trueOrFalse);
sqInt pushFloat(double f);
sqInt pushInteger(sqInt integerValue);
double stackFloatValue(sqInt offset);
sqInt stackIntegerValue(sqInt offset);
sqInt stackObjectValue(sqInt offset);
sqInt stackValue(sqInt offset);

/*** variables ***/

extern sqInt (*compilerHooks[])();
extern sqInt setCompilerInitialized(sqInt flagValue);

/* InterpreterProxy methodsFor: 'object access' */
sqInt argumentCountOf(sqInt methodPointer);
void *arrayValueOf(sqInt oop);
sqInt byteSizeOf(sqInt oop);
void *fetchArrayofObject(sqInt fieldIndex, sqInt objectPointer);
sqInt fetchClassOf(sqInt oop);
double fetchFloatofObject(sqInt fieldIndex, sqInt objectPointer);
sqInt fetchIntegerofObject(sqInt fieldIndex, sqInt objectPointer);
sqInt fetchPointerofObject(sqInt index, sqInt oop);
/* sqInt fetchWordofObject(sqInt fieldIndex, sqInt oop); *
* has been rescinded as of VMMaker 3.8 and the 64bitclean VM *
* work. To support old plugins we keep a valid function in *
* the same location in the VM struct but rename it to *
* something utterly horrible to scare off the natives. A new *
* equivalent but 64 bit valid function is added as *
* 'fetchLong32OfObject' */
sqInt obsoleteDontUseThisFetchWordofObject(sqInt index, sqInt oop);
sqInt fetchLong32ofObject(sqInt index, sqInt oop);
void *firstFixedField(sqInt oop);
void *firstIndexableField(sqInt oop);
sqInt literalofMethod(sqInt offset, sqInt methodPointer);
sqInt literalCountOf(sqInt methodPointer);
sqInt methodArgumentCount(void);
sqInt methodPrimitiveIndex(void);
sqInt primitiveMethod(void);
sqInt primitiveIndexOf(sqInt methodPointer);
sqInt sizeOfSTArrayFromCPrimitive(void *cPtr);
sqInt slotSizeOf(sqInt oop);
sqInt stObjectat(sqInt array, sqInt index);
sqInt stObjectatput(sqInt array, sqInt index, sqInt value);
sqInt stSizeOf(sqInt oop);
sqInt storeIntegerofObjectwithValue(sqInt index, sqInt oop, sqInt integer);
sqInt storePointerofObjectwithValue(sqInt index, sqInt oop, sqInt valuePointer);

/* InterpreterProxy methodsFor: 'testing' */
sqInt isKindOf(sqInt oop, char *aString);
sqInt isMemberOf(sqInt oop, char *aString);
sqInt isBytes(sqInt oop);
sqInt isFloatObject(sqInt oop);
sqInt isIndexable(sqInt oop);
sqInt isIntegerObject(sqInt objectPointer);
sqInt isIntegerValue(sqInt intValue);
sqInt isPointers(sqInt oop);
sqInt isWeak(sqInt oop);
sqInt isWords(sqInt oop);
sqInt isWordsOrBytes(sqInt oop);
sqInt includesBehaviorThatOf(sqInt aClass, sqInt aSuperClass);
sqInt isArray(sqInt oop);

/* InterpreterProxy methodsFor: 'converting' */
sqInt booleanValueOf(sqInt obj);
sqInt checkedIntegerValueOf(sqInt intOop);
sqInt floatObjectOf(double aFloat);
double floatValueOf(sqInt oop);
sqInt integerObjectOf(sqInt value);
sqInt integerValueOf(sqInt oop);
sqInt positive32BitIntegerFor(sqInt integerValue);
sqInt positive32BitValueOf(sqInt oop);
sqInt signed32BitIntegerFor(sqInt integerValue);
sqInt signed32BitValueOf(sqInt oop);
sqInt positive64BitIntegerFor(sqLong integerValue);
sqLong positive64BitValueOf(sqInt oop);
sqInt signed64BitIntegerFor(sqLong integerValue);
sqLong signed64BitValueOf(sqInt oop);

/* InterpreterProxy methodsFor: 'special objects' */
sqInt characterTable(void);
sqInt displayObject(void);
sqInt falseObject(void);
sqInt nilObject(void);
sqInt trueObject(void);

/* InterpreterProxy methodsFor: 'special classes' */
sqInt classArray(void);
sqInt classBitmap(void);
sqInt classByteArray(void);
sqInt classCharacter(void);
sqInt classFloat(void);
sqInt classLargePositiveInteger(void);
sqInt classLargeNegativeInteger(void);
sqInt classPoint(void);
sqInt classSemaphore(void);
sqInt classSmallInteger(void);
sqInt classString(void);

/* InterpreterProxy methodsFor: 'instance creation' */
sqInt clone(sqInt oop);
sqInt instantiateClassindexableSize(sqInt classPointer, sqInt size);
sqInt makePointwithxValueyValue(sqInt xValue, sqInt yValue);
sqInt popRemappableOop(void);
sqInt pushRemappableOop(sqInt oop);

/* InterpreterProxy methodsFor: 'other' */
sqInt becomewith(sqInt array1, sqInt array2);
sqInt byteSwapped(sqInt w);
sqInt failed(void);
sqInt fullDisplayUpdate(void);
sqInt fullGC(void);
sqInt incrementalGC(void);
sqInt primitiveFail(void);
sqInt showDisplayBitsLeftTopRightBottom(sqInt aForm, sqInt l, sqInt t, sqInt r, sqInt b);
sqInt signalSemaphoreWithIndex(sqInt semaIndex);
sqInt success(sqInt aBoolean);
sqInt superclassOf(sqInt classPointer);
sqInt ioMicroMSecs(void);
sqInt forceInterruptCheck(void);
sqInt getThisSessionID(void);
sqInt ioFilenamefromStringofLengthresolveAliases(char* aCharBuffer, char* filenameIndex, sqInt filenameLength, sqInt resolveFlag);
sqInt vmEndianness(void);

/* InterpreterProxy methodsFor: 'BitBlt support' */
sqInt loadBitBltFrom(sqInt bbOop);
sqInt copyBits(void);
sqInt copyBitsFromtoat(sqInt leftX, sqInt rightX, sqInt yValue);

/* InterpreterProxy methodsFor: 'FFI support' */
sqInt classExternalAddress(void);
sqInt classExternalData(void);
sqInt classExternalFunction(void);
sqInt classExternalLibrary(void);
sqInt classExternalStructure(void);
sqInt ioLoadModuleOfLength(sqInt moduleNameIndex, sqInt moduleNameLength);
sqInt ioLoadSymbolOfLengthFromModule(sqInt functionNameIndex, sqInt functionNameLength, sqInt moduleHandle);
sqInt isInMemory(sqInt address);

void *ioLoadFunctionFrom(char *fnName, char *modName);

/* Proxy declarations for v1.8 */
sqInt callbackEnter(sqInt *callbackID);
sqInt callbackLeave(sqInt callbackID);
sqInt addGCRoot(sqInt *varLoc);
sqInt removeGCRoot(sqInt *varLoc);

struct VirtualMachine *VM = NULL;

static sqInt majorVersion(void) {
return VM_PROXY_MAJOR;
}

static sqInt minorVersion(void) {
return VM_PROXY_MINOR;
}

static CompilerHook *compilerHookVector(void) {
return compilerHooks;
}

struct VirtualMachine* sqGetInterpreterProxy(void)
{
if(VM) return VM;
VM = (struct VirtualMachine *)calloc(1, sizeof(VirtualMachine));
/* Initialize Function pointers */
VM->majorVersion = majorVersion;
VM->minorVersion = minorVersion;

/* InterpreterProxy methodsFor: 'stack access' */
VM->pop = pop;
VM->popthenPush = popthenPush;
VM->push = push;
VM->pushBool = pushBool;
VM->pushFloat = pushFloat;
VM->pushInteger = pushInteger;
VM->stackFloatValue = stackFloatValue;
VM->stackIntegerValue = stackIntegerValue;
VM->stackObjectValue = stackObjectValue;
VM->stackValue = stackValue;

/* InterpreterProxy methodsFor: 'object access' */
VM->argumentCountOf = argumentCountOf;
VM->arrayValueOf = arrayValueOf;
VM->byteSizeOf = byteSizeOf;
VM->fetchArrayofObject = fetchArrayofObject;
VM->fetchClassOf = fetchClassOf;
VM->fetchFloatofObject = fetchFloatofObject;
VM->fetchIntegerofObject = fetchIntegerofObject;
VM->fetchPointerofObject = fetchPointerofObject;
VM->obsoleteDontUseThisFetchWordofObject = obsoleteDontUseThisFetchWordofObject;
VM->firstFixedField = firstFixedField;
VM->firstIndexableField = firstIndexableField;
VM->literalofMethod = literalofMethod;
VM->literalCountOf = literalCountOf;
VM->methodArgumentCount = methodArgumentCount;
VM->methodPrimitiveIndex = methodPrimitiveIndex;
VM->primitiveIndexOf = primitiveIndexOf;
VM->primitiveMethod = primitiveMethod;
VM->sizeOfSTArrayFromCPrimitive = sizeOfSTArrayFromCPrimitive;
VM->slotSizeOf = slotSizeOf;
VM->stObjectat = stObjectat;
VM->stObjectatput = stObjectatput;
VM->stSizeOf = stSizeOf;
VM->storeIntegerofObjectwithValue = storeIntegerofObjectwithValue;
VM->storePointerofObjectwithValue = storePointerofObjectwithValue;

/* InterpreterProxy methodsFor: 'testing' */
VM->isKindOf = isKindOf;
VM->isMemberOf = isMemberOf;
VM->isBytes = isBytes;
VM->isFloatObject = isFloatObject;
VM->isIndexable = isIndexable;
VM->isIntegerObject = isIntegerObject;
VM->isIntegerValue = isIntegerValue;
VM->isPointers = isPointers;
VM->isWeak = isWeak;
VM->isWords = isWords;
VM->isWordsOrBytes = isWordsOrBytes;

/* InterpreterProxy methodsFor: 'converting' */
VM->booleanValueOf = booleanValueOf;
VM->checkedIntegerValueOf = checkedIntegerValueOf;
VM->floatObjectOf = floatObjectOf;
VM->floatValueOf = floatValueOf;
VM->integerObjectOf = integerObjectOf;
VM->integerValueOf = integerValueOf;
VM->positive32BitIntegerFor = positive32BitIntegerFor;
VM->positive32BitValueOf = positive32BitValueOf;

/* InterpreterProxy methodsFor: 'special objects' */
VM->characterTable = characterTable;
VM->displayObject = displayObject;
VM->falseObject = falseObject;
VM->nilObject = nilObject;
VM->trueObject = trueObject;

/* InterpreterProxy methodsFor: 'special classes' */
VM->classArray = classArray;
VM->classBitmap = classBitmap;
VM->classByteArray = classByteArray;
VM->classCharacter = classCharacter;
VM->classFloat = classFloat;
VM->classLargePositiveInteger = classLargePositiveInteger;
VM->classPoint = classPoint;
VM->classSemaphore = classSemaphore;
VM->classSmallInteger = classSmallInteger;
VM->classString = classString;

/* InterpreterProxy methodsFor: 'instance creation' */
VM->clone = clone;
VM->instantiateClassindexableSize = instantiateClassindexableSize;
VM->makePointwithxValueyValue = makePointwithxValueyValue;
VM->popRemappableOop = popRemappableOop;
VM->pushRemappableOop = pushRemappableOop;

/* InterpreterProxy methodsFor: 'other' */
VM->becomewith = becomewith;
VM->byteSwapped = byteSwapped;
VM->failed = failed;
VM->fullDisplayUpdate = fullDisplayUpdate;
VM->fullGC = fullGC;
VM->incrementalGC = incrementalGC;
VM->primitiveFail = primitiveFail;
VM->showDisplayBitsLeftTopRightBottom = showDisplayBitsLeftTopRightBottom;
VM->signalSemaphoreWithIndex = signalSemaphoreWithIndex;
VM->success = success;
VM->superclassOf = superclassOf;

VM->compilerHookVector= compilerHookVector;
VM->setCompilerInitialized= setCompilerInitialized;

#if VM_PROXY_MINOR > 1

/* InterpreterProxy methodsFor: 'BitBlt support' */
VM->loadBitBltFrom = loadBitBltFrom;
VM->copyBits = copyBits;
VM->copyBitsFromtoat = copyBitsFromtoat;

#endif

#if VM_PROXY_MINOR > 2

/* InterpreterProxy methodsFor: 'FFI support' */
VM->classExternalAddress = classExternalAddress;
VM->classExternalData = classExternalData;
VM->classExternalFunction = classExternalFunction;
VM->classExternalLibrary = classExternalLibrary;
VM->classExternalStructure = classExternalStructure;
VM->ioLoadModuleOfLength = ioLoadModuleOfLength;
VM->ioLoadSymbolOfLengthFromModule = ioLoadSymbolOfLengthFromModule;
VM->isInMemory = isInMemory;
VM->signed32BitIntegerFor = signed32BitIntegerFor;
VM->signed32BitValueOf = signed32BitValueOf;
VM->includesBehaviorThatOf = includesBehaviorThatOf;
VM->classLargeNegativeInteger = classLargeNegativeInteger;

#endif

#if VM_PROXY_MINOR > 3

VM->ioLoadFunctionFrom = ioLoadFunctionFrom;
VM->ioMicroMSecs = ioMicroMSecs;

#endif

#if VM_PROXY_MINOR > 4

VM->positive64BitIntegerFor = positive64BitIntegerFor;
VM->positive64BitValueOf = positive64BitValueOf;
VM->signed64BitIntegerFor = signed64BitIntegerFor;
VM->signed64BitValueOf = signed64BitValueOf;

#endif

#if VM_PROXY_MINOR > 5
VM->isArray = isArray;
VM->forceInterruptCheck = forceInterruptCheck;
#endif

#if VM_PROXY_MINOR > 6
VM->fetchLong32ofObject = fetchLong32ofObject;
VM->getThisSessionID = getThisSessionID;
VM->ioFilenamefromStringofLengthresolveAliases = ioFilenamefromStringofLengthresolveAliases;
VM->vmEndianness = vmEndianness;
#endif

#if VM_PROXY_MINOR > 7
VM->callbackEnter = callbackEnter;
VM->callbackLeave = callbackLeave;
VM->addGCRoot = addGCRoot;
VM->removeGCRoot = removeGCRoot;
#endif

return VM;
}

#ifndef _SqueakVM_H
#define _SqueakVM_H

/* Increment the following number if you change the order of
functions listed or if you remove functions */
#define VM_PROXY_MAJOR 1

/* Note: You can define a different VM_PROXY_MINOR if the plugin
should work with older VMs. */
#ifndef VM_PROXY_MINOR
/* Increment the following number if you add functions at the end */
#define VM_PROXY_MINOR 8
#endif

#include "sqMemoryAccess.h"

typedef sqInt (*CompilerHook)();

struct VirtualMachine* sqGetInterpreterProxy(void);

typedef struct VirtualMachine {
sqInt (*minorVersion)(void);
sqInt (*majorVersion)(void);

/* InterpreterProxy methodsFor: 'stack access' */

sqInt (*pop)(sqInt nItems);
sqInt (*popthenPush)(sqInt nItems, sqInt oop);
sqInt (*push)(sqInt object);
sqInt (*pushBool)(sqInt trueOrFalse);
sqInt (*pushFloat)(double f);
sqInt (*pushInteger)(sqInt integerValue);
double (*stackFloatValue)(sqInt offset);
sqInt (*stackIntegerValue)(sqInt offset);
sqInt (*stackObjectValue)(sqInt offset);
sqInt (*stackValue)(sqInt offset);

/* InterpreterProxy methodsFor: 'object access' */

sqInt (*argumentCountOf)(sqInt methodPointer);
void *(*arrayValueOf)(sqInt oop);
sqInt (*byteSizeOf)(sqInt oop);
void *(*fetchArrayofObject)(sqInt fieldIndex, sqInt objectPointer);
sqInt (*fetchClassOf)(sqInt oop);
double (*fetchFloatofObject)(sqInt fieldIndex, sqInt objectPointer);
sqInt (*fetchIntegerofObject)(sqInt fieldIndex, sqInt objectPointer);
sqInt (*fetchPointerofObject)(sqInt fieldIndex, sqInt oop);
/* sqInt (*fetchWordofObject)(sqInt fieldFieldIndex, sqInt oop); *
* has been rescinded as of VMMaker 3.8 and the 64bitclean VM *
* work. To support old plugins we keep a valid function in *
* the same location in the VM struct but rename it to *
* something utterly horrible to scare off the natives. A new *
* equivalent but 64 bit valid function is added as *
* 'fetchLong32OfObject' */
sqInt (*obsoleteDontUseThisFetchWordofObject)(sqInt fieldFieldIndex, sqInt oop);
void *(*firstFixedField)(sqInt oop);
void *(*firstIndexableField)(sqInt oop);
sqInt (*literalofMethod)(sqInt offset, sqInt methodPointer);
sqInt (*literalCountOf)(sqInt methodPointer);
sqInt (*methodArgumentCount)(void);
sqInt (*methodPrimitiveIndex)(void);
sqInt (*primitiveIndexOf)(sqInt methodPointer);
sqInt (*sizeOfSTArrayFromCPrimitive)(void *cPtr);
sqInt (*slotSizeOf)(sqInt oop);
sqInt (*stObjectat)(sqInt array, sqInt fieldIndex);
sqInt (*stObjectatput)(sqInt array, sqInt fieldIndex, sqInt value);
sqInt (*stSizeOf)(sqInt oop);
sqInt (*storeIntegerofObjectwithValue)(sqInt fieldIndex, sqInt oop, sqInt integer);
sqInt (*storePointerofObjectwithValue)(sqInt fieldIndex, sqInt oop, sqInt valuePointer);

/* InterpreterProxy methodsFor: 'testing' */

sqInt (*isKindOf)(sqInt oop, char *aString);
sqInt (*isMemberOf)(sqInt oop, char *aString);
sqInt (*isBytes)(sqInt oop);
sqInt (*isFloatObject)(sqInt oop);
sqInt (*isIndexable)(sqInt oop);
sqInt (*isIntegerObject)(sqInt objectPointer);
sqInt (*isIntegerValue)(sqInt intValue);
sqInt (*isPointers)(sqInt oop);
sqInt (*isWeak)(sqInt oop);
sqInt (*isWords)(sqInt oop);
sqInt (*isWordsOrBytes)(sqInt oop);

/* InterpreterProxy methodsFor: 'converting' */

sqInt (*booleanValueOf)(sqInt obj);
sqInt (*checkedIntegerValueOf)(sqInt intOop);
sqInt (*floatObjectOf)(double aFloat);
double (*floatValueOf)(sqInt oop);
sqInt (*integerObjectOf)(sqInt value);
sqInt (*integerValueOf)(sqInt oop);
sqInt (*positive32BitIntegerFor)(sqInt integerValue);
sqInt (*positive32BitValueOf)(sqInt oop);

/* InterpreterProxy methodsFor: 'special objects' */

sqInt (*characterTable)(void);
sqInt (*displayObject)(void);
sqInt (*falseObject)(void);
sqInt (*nilObject)(void);
sqInt (*trueObject)(void);

/* InterpreterProxy methodsFor: 'special classes' */

sqInt (*classArray)(void);
sqInt (*classBitmap)(void);
sqInt (*classByteArray)(void);
sqInt (*classCharacter)(void);
sqInt (*classFloat)(void);
sqInt (*classLargePositiveInteger)(void);
sqInt (*classPoint)(void);
sqInt (*classSemaphore)(void);
sqInt (*classSmallInteger)(void);
sqInt (*classString)(void);

/* InterpreterProxy methodsFor: 'instance creation' */

sqInt (*clone)(sqInt oop);
sqInt (*instantiateClassindexableSize)(sqInt classPointer, sqInt size);
sqInt (*makePointwithxValueyValue)(sqInt xValue, sqInt yValue);
sqInt (*popRemappableOop)(void);
sqInt (*pushRemappableOop)(sqInt oop);

/* InterpreterProxy methodsFor: 'other' */

sqInt (*becomewith)(sqInt array1, sqInt array2);
sqInt (*byteSwapped)(sqInt w);
sqInt (*failed)(void);
sqInt (*fullDisplayUpdate)(void);
sqInt (*fullGC)(void);
sqInt (*incrementalGC)(void);
sqInt (*primitiveFail)(void);
sqInt (*showDisplayBitsLeftTopRightBottom)(sqInt aForm, sqInt l, sqInt t, sqInt r, sqInt b);
sqInt (*signalSemaphoreWithIndex)(sqInt semaIndex);
sqInt (*success)(sqInt aBoolean);
sqInt (*superclassOf)(sqInt classPointer);

/* InterpreterProxy methodsFor: 'compiler' */

CompilerHook *(*compilerHookVector)(void);
sqInt (*setCompilerInitialized)(sqInt initFlag);

#if VM_PROXY_MINOR > 1

/* InterpreterProxy methodsFor: 'BitBlt support' */

sqInt (*loadBitBltFrom)(sqInt bbOop);
sqInt (*copyBits)(void);
sqInt (*copyBitsFromtoat)(sqInt leftX, sqInt rightX, sqInt yValue);

#endif

#if VM_PROXY_MINOR > 2

sqInt (*classLargeNegativeInteger)(void);
sqInt (*signed32BitIntegerFor)(sqInt integerValue);
sqInt (*signed32BitValueOf)(sqInt oop);
sqInt (*includesBehaviorThatOf)(sqInt aClass, sqInt aSuperClass);
sqInt (*primitiveMethod)(void);

/* InterpreterProxy methodsFor: 'FFI support' */

sqInt (*classExternalAddress)(void);
sqInt (*classExternalData)(void);
sqInt (*classExternalFunction)(void);
sqInt (*classExternalLibrary)(void);
sqInt (*classExternalStructure)(void);
sqInt (*ioLoadModuleOfLength)(sqInt modIndex, sqInt modLength);
sqInt (*ioLoadSymbolOfLengthFromModule)(sqInt fnIndex, sqInt fnLength, sqInt handle);
sqInt (*isInMemory)(sqInt address);

#endif

#if VM_PROXY_MINOR > 3

void *(*ioLoadFunctionFrom)(char *fnName, char *modName);
sqInt (*ioMicroMSecs)(void);

#endif

#if VM_PROXY_MINOR > 4

# if !defined(sqLong)
# if _MSC_VER
# define sqLong __int64
# else
# define sqLong long long
# endif
# endif

sqInt (*positive64BitIntegerFor)(sqLong integerValue);
sqLong (*positive64BitValueOf)(sqInt oop);
sqInt (*signed64BitIntegerFor)(sqLong integerValue);
sqLong (*signed64BitValueOf)(sqInt oop);

#endif

#if VM_PROXY_MINOR > 5
sqInt (*isArray)(sqInt oop);
sqInt (*forceInterruptCheck)(void);
#endif

#if VM_PROXY_MINOR > 6
sqInt (*fetchLong32ofObject)(sqInt fieldFieldIndex, sqInt oop);
sqInt (*getThisSessionID)(void);
sqInt (*ioFilenamefromStringofLengthresolveAliases)(char* aCharBuffer, char* filenameIndex, sqInt filenameLength, sqInt resolveFlag);
sqInt (*vmEndianness)(void);
#endif

#if VM_PROXY_MINOR > 7
/* New methods for proxy version 1.8 */

/* callbackEnter: Re-enter the interpreter loop for a callback.
Arguments:
callbackID: Pointer to a location receiving the callback ID
used in callbackLeave
Returns: True if successful, false otherwise */
sqInt (*callbackEnter)(sqInt *callbackID);

/* callbackLeave: Leave the interpreter from a previous callback
Arguments:
callbackID: The ID of the callback received from callbackEnter()
Returns: True if succcessful, false otherwise. */
sqInt (*callbackLeave)(sqInt callbackID);

/* addGCRoot: Add a variable location to the garbage collector.
The contents of the variable location will be updated accordingly.
Arguments:
varLoc: Pointer to the variable location
Returns: True if successful, false otherwise. */
sqInt (*addGCRoot)(sqInt *varLoc);

/* removeGCRoot: Remove a variable location from the garbage collector.
Arguments:
varLoc: Pointer to the variable location
Returns: True if successful, false otherwise.
*/
sqInt (*removeGCRoot)(sqInt *varLoc);
#endif

} VirtualMachine;

#endif /* _SqueakVM_H */

ExtraGCRoots.cs.gz (5K) Download Attachment
Callbacks.cs.gz (10K) Download Attachment
ExampleCallbacks.cs.gz (2K) Download Attachment

Re: Inliner strangeness

2006-06-09T11:15:44Z

Actually I think I've seen

self touch: foo

which is removed by the CCodeGenerator, mind I've not check this to
see when it's removed in relationship to the inliner logic.

On 9-Jun-06, at 1:08 AM, Bert Freudenberg wrote:

> The pattern to avoid this inlining "strangeness" would be
>
> Interpreter>>getFoo
> ^self cCode: 'foo' inSmalltalk: [foo]
>
> so the inliner sees the second access.
>
> - Bert -
>
> Am 09.06.2006 um 00:47 schrieb John M McIntosh:
>
>> This was done on purpose years ago to inline all the variables in
>> the GC logic.
>>
>> If you have one accessor and one usage of the variable in another
>> routine and say not to inline the accessor,
>> then the inliner won't fold the global into a local variable.
>> Your code example follows the rules nicely because you've only
>> one usage of the foo variable we can see and why make it a global...
>>
>>
>> On 8-Jun-06, at 1:53 PM, Andreas Raab wrote:
>>
>>> Hi -
>>>
>>> I don't know if this behavior has been in the CCode inliner
>>> before but I just noticed that the inliner will forcefully
>>> convert iVars to temps if that iVar is only explicitly referred
>>> to in a single method. Like, for example here:
>>>
>>> Interpreter>>getFoo
>>> ^self cCode: 'foo'
>>>
>>> Interpreter>>setFoo: fooValue
>>> foo := fooValue.
>>>
>>> The above will cause the inliner to remove foo from the regular
>>> interpreter variables (even if declared via #declareCVarsIn:) and
>>> move it into #setFoo:. With the foreseeable result of creating
>>> total and utter nonsense in the resulting C code.
>>>
>>> Has anyone seen that before?
>>>
>>> Cheers,
>>> - Andreas
>
>

--
========================================================================
===
John M. McIntosh <johnmci@...> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===

Re: [Fwd: Re: Keeping oops across primitives]

2006-06-09T03:01:32Z

Andreas Raab wrote:
> Actually, this is an interesting thought. I have the need for managing a
> dynamic array of roots but this could be handled just as easily by
> tracking a variable pointing to a Squeak array.

A variable in C is more-or-less a one-place array, so perhaps supporting
arrays is the simpler option?

{
sqInt myRoot = ...;
vm->addToVmRoots(&myRoot, 1, NULL);
...
vm->addToVmRoots(NULL, 0, &myRoot);
}

#define WITH_ROOT(vm, var, blk) \
{ (vm)->addToVmRoots(&(var), 1, NULL); \
blk; \
(vm)->addToVmRoots(NULL, 0, &(var)); }

{
sqInt myRoot2 = ...;
WITH_ROOT(vm, myRoot2, {
...
});
}

Re: Inliner strangeness

2006-06-09T02:08:13Z

The pattern to avoid this inlining "strangeness" would be

Interpreter>>getFoo
^self cCode: 'foo' inSmalltalk: [foo]

so the inliner sees the second access.

- Bert -

Am 09.06.2006 um 00:47 schrieb John M McIntosh:

> This was done on purpose years ago to inline all the variables in
> the GC logic.
>
> If you have one accessor and one usage of the variable in another
> routine and say not to inline the accessor,
> then the inliner won't fold the global into a local variable. Your
> code example follows the rules nicely because you've only
> one usage of the foo variable we can see and why make it a global...
>
>
> On 8-Jun-06, at 1:53 PM, Andreas Raab wrote:
>
>> Hi -
>>
>> I don't know if this behavior has been in the CCode inliner before
>> but I just noticed that the inliner will forcefully convert iVars
>> to temps if that iVar is only explicitly referred to in a single
>> method. Like, for example here:
>>
>> Interpreter>>getFoo
>> ^self cCode: 'foo'
>>
>> Interpreter>>setFoo: fooValue
>> foo := fooValue.
>>
>> The above will cause the inliner to remove foo from the regular
>> interpreter variables (even if declared via #declareCVarsIn:) and
>> move it into #setFoo:. With the foreseeable result of creating
>> total and utter nonsense in the resulting C code.
>>
>> Has anyone seen that before?
>>
>> Cheers,
>> - Andreas

Re: Inliner strangeness

2006-06-08T16:47:37Z

This was done on purpose years ago to inline all the variables in the
GC logic.

If you have one accessor and one usage of the variable in another
routine and say not to inline the accessor,
then the inliner won't fold the global into a local variable. Your
code example follows the rules nicely because you've only
one usage of the foo variable we can see and why make it a global...

On 8-Jun-06, at 1:53 PM, Andreas Raab wrote:

> Hi -
>
> I don't know if this behavior has been in the CCode inliner before
> but I just noticed that the inliner will forcefully convert iVars
> to temps if that iVar is only explicitly referred to in a single
> method. Like, for example here:
>
> Interpreter>>getFoo
> ^self cCode: 'foo'
>
> Interpreter>>setFoo: fooValue
> foo := fooValue.
>
> The above will cause the inliner to remove foo from the regular
> interpreter variables (even if declared via #declareCVarsIn:) and
> move it into #setFoo:. With the foreseeable result of creating
> total and utter nonsense in the resulting C code.
>
> Has anyone seen that before?
>
> Cheers,
> - Andreas

Re: Callbacks, simplified.

2006-06-08T14:57:18Z

Andreas Raab wrote:
> > Do you have any thoughts on how this could be handled better?
>
> How about we just suspend the currently active process when we re-enter
> the interpreter? As long as the callback is synchronous (it better be)
> this should work just fine, right?

Yes, that should do the trick. I tried doing something like this awhile
back, but couldn't get it to work reliably. I suspect the problem was
that the process oop might move during a callback, in which case trying
to resume it would cause a crash. It sounds like your other changes to
keep oops across primitives would solve this.

.. Rob

>
> Cheers,
> - Andreas
>
> Rob Gayvert wrote:
>
>> tim Rowledge wrote:
>>
>>>
>>> On 6-Jun-06, at 5:00 PM, Andreas Raab wrote:
>>>
>>>> tim Rowledge wrote:
>>>>
>>>>> How are you proposing to deal with the callback at the higher
>>>>> levels? Is the plugin going to be allowed to cons up a message and
>>>>> 'send' it? Or.....?
>>>>
>>>>
>>>>
>>>> This should be up to the plugin. I can't think of a good interface
>>>> right now given that we don't have enough examples to look at and
>>>> learn from. Personally, I'm just signaling a semaphore before the
>>>> callback and have the image "pull up" the arguments via primitives.
>>>> This avoids the need to do too much at the primitive level.
>>>
>>>
>>>
>>> So would simply using the normal semaphore signalling be ok? We
>>> already have external semaphore capability so it would certainly be
>>> simple to provide! If we implemented callbacks by taking a block (or
>>> a MessageSend?), making a Process that will use it, make the process
>>> wait on a Semaphore and pass the semaphore index down to the
>>> plugin, then signalling the semaphore would run the block/whatever
>>> and presumably ask the plugin for relevant arguments. As long as it
>>> can be non-synchronous that should work for a lot of cases, surely?
>>>
>>
>> Hi guys,
>>
>> This is basically what I'm currently doing in wxSqueak. I have two
>> different flavors of callbacks, one for event loops and another for
>> other callbacks. The only real difference between these two is that
>> the non-event callbacks have to handle a variety of arguments. In both
>> cases the callbacks must appear to be handled synchronously from the
>> viewpoint of the (wx) calling routine. The only serious difficulty
>> I've encountered with this scheme is with nested callbacks. I have a
>> number of cases where a callback handler triggers another callback.
>> The problem is that when the second callback is handled, the process
>> in which the first primitive was called may resume prematurely,
>> causing the first primitive to get an incorrect return value.
>>
>> The only way I found to reliably handle this scenario is to have the
>> first primitive pass in another semaphore and a pointer in which to
>> store the return value, and have the primitive signal the semphore
>> when it's done. It's a bit ugly, but it does work. It would be much
>> better if the processes involved could be controlled by the framework.
>>
>> Do you have any thoughts on how this could be handled better?
>>
>> .. Rob
>>
>>
>>
>>
>>
>>
>

Inliner strangeness

2006-06-08T14:53:33Z

Hi -

I don't know if this behavior has been in the CCode inliner before but I
just noticed that the inliner will forcefully convert iVars to temps if
that iVar is only explicitly referred to in a single method. Like, for
example here:

Interpreter>>getFoo
^self cCode: 'foo'

Interpreter>>setFoo: fooValue
foo := fooValue.

The above will cause the inliner to remove foo from the regular
interpreter variables (even if declared via #declareCVarsIn:) and move
it into #setFoo:. With the foreseeable result of creating total and
utter nonsense in the resulting C code.

Has anyone seen that before?

Cheers,
- Andreas

[Fwd: Re: Keeping oops across primitives]

2006-06-08T13:33:30Z

Oops, I sent this accidentally only to Bryce...

-------- Original Message --------
Subject: Re: Keeping oops across primitives
Date: Thu, 08 Jun 2006 10:50:54 -0700
From: Andreas Raab <andreas.raab@...>
To: Bryce Kampjes <bryce@...>
References: <4484D055.8020603@...>
<17543.20996.659703.227330@...>

Hi Bryce -

> > Question: Does anyone see a serious problem with the above proposal? I'm
> > about to implement this right away so if you see an issue with it,
> > please let me know.
>
> Your solution sounds fine. I'd prefer to be able to register variables
> as roots rather than having to place things in arrays for my use. But
> then I'm just tracking entry points rather than individual objects (a
> dictionary that maps classes and selectors to natively compiled
> methods and an array of objects so natively compiled code can access
> objects).

Actually, this is an interesting thought. I have the need for managing a
dynamic array of roots but this could be handled just as easily by
tracking a variable pointing to a Squeak array.

So, does anyone feel strongly about going either way?

Cheers,
- Andreas

Re: Callbacks, simplified.

2006-06-08T12:03:12Z

> Do you have any thoughts on how this could be handled better?

How about we just suspend the currently active process when we re-enter
the interpreter? As long as the callback is synchronous (it better be)
this should work just fine, right?

Cheers,
- Andreas

Rob Gayvert wrote:

> tim Rowledge wrote:
>>
>> On 6-Jun-06, at 5:00 PM, Andreas Raab wrote:
>>
>>> tim Rowledge wrote:
>>>
>>>> How are you proposing to deal with the callback at the higher
>>>> levels? Is the plugin going to be allowed to cons up a message and
>>>> 'send' it? Or.....?
>>>
>>>
>>> This should be up to the plugin. I can't think of a good interface
>>> right now given that we don't have enough examples to look at and
>>> learn from. Personally, I'm just signaling a semaphore before the
>>> callback and have the image "pull up" the arguments via primitives.
>>> This avoids the need to do too much at the primitive level.
>>
>>
>> So would simply using the normal semaphore signalling be ok? We
>> already have external semaphore capability so it would certainly be
>> simple to provide! If we implemented callbacks by taking a block (or
>> a MessageSend?), making a Process that will use it, make the process
>> wait on a Semaphore and pass the semaphore index down to the plugin,
>> then signalling the semaphore would run the block/whatever and
>> presumably ask the plugin for relevant arguments. As long as it can
>> be non-synchronous that should work for a lot of cases, surely?
>>
>
> Hi guys,
>
> This is basically what I'm currently doing in wxSqueak. I have two
> different flavors of callbacks, one for event loops and another for
> other callbacks. The only real difference between these two is that the
> non-event callbacks have to handle a variety of arguments. In both cases
> the callbacks must appear to be handled synchronously from the viewpoint
> of the (wx) calling routine. The only serious difficulty I've
> encountered with this scheme is with nested callbacks. I have a number
> of cases where a callback handler triggers another callback. The problem
> is that when the second callback is handled, the process in which the
> first primitive was called may resume prematurely, causing the first
> primitive to get an incorrect return value.
>
> The only way I found to reliably handle this scenario is to have the
> first primitive pass in another semaphore and a pointer in which to
> store the return value, and have the primitive signal the semphore when
> it's done. It's a bit ugly, but it does work. It would be much better if
> the processes involved could be controlled by the framework.
>
> Do you have any thoughts on how this could be handled better?
>
> .. Rob
>
>
>
>
>
>

Re: InterpreterProxy>>signed64BitIntegerFor: badly broken

2006-06-07T23:02:40Z

On 7-Jun-06, at 6:58 PM, Andreas Raab wrote:

> Hi Guys -
>
> I don't know if you ever used the above method but it's horribly,
> horribly broken. I wrote a little test primitive (see below) that
> simply used signed64BitIntegerFor(signed64BitValueOf(oop)) and then
> a loop like here:
>
> 0 to: 63 do:[:i|
> n := 1 bitShift: i.
> (self test64BitInt: n) = n ifFalse:[self halt: i].
> ].
>
> Starting from i = 31 Every. Last. Result. Is Wrong. Can you imagine?
>
> It gets even better, since it's broken in different ways: For i=31
> the result is negated, for everything beyound 31 the resulting
> large integer is non-normalized (and therefore not comparing
> correctly).
>
> Any ideas?

Well for starters the signed64BitIntegerFor: code assumes an 8 byte
large integer no matter what the value being converted so that's
going to cause your non-normalized problem. I'm fairly sure you can
work out how to fix that bit quickly enough.

I'm not absolutely sure(and I can't be bothered to look it up right
now) but wouldn't 1<<31 be a negative value when treated as a 32 bit
word? It looks to me as if signed32BitInteger might be the wrong
thing to use in signed64itInteger, with positive32BitInteger a bit
more plausible.

I have vague memories of when this code was written, mostly of it
being related to long file pointers in OSs I wasn't running at that
time. Thus I would have relied upon testing by involved parties and
taken their word as to the viability of the code. I guess that once
again the value of good tests is demonstrated.

tim
--
tim Rowledge; tim@...; http://www.rowledge.org/tim
Strange OpCodes: VMB: Verify, then Make Bad