Vm-dev June 2006

vm-dev@lists.squeakfoundation.org

12 participants
13 discussions

Re: InterpreterSimulator and friends
by Michael van der Gulik 25 Jun '06

25 Jun '06

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(a)rowledge.org; http://www.rowledge.org/tim > Press [ESC] to detonate or any other key to explode. > > > > >

1 0

ObjectiveCPlugin, VMMaker usage
by Damien Pollet 25 Jun '06

25 Jun '06

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

1 1

InterpreterSimulator and friends
by Michael van der Gulik 24 Jun '06

24 Jun '06

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.

1 0

VM (callback+variables) changes
by Andreas Raab 14 Jun '06

14 Jun '06

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

2 4

Squeak port to Amiga progress 6-10
by Tim Johnson 11 Jun '06

11 Jun '06

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.

1 1

[Fwd: Re: Keeping oops across primitives]
by Andreas Raab 09 Jun '06

09 Jun '06

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(a)gmx.de> To: Bryce Kampjes <bryce(a)kampjes.demon.co.uk> References: <4484D055.8020603(a)gmx.de> <17543.20996.659703.227330(a)localhost.localdomain> 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

2 2

Callbacks, simplified.
by Andreas Raab 09 Jun '06

09 Jun '06

Folks - Another one of the issues I really need a solution for is simple callback support into the interpreter. For me, the simplest thing to do that can potentially support all the relevant use cases is to merely provide an interface that (via setjmp/longjmp) ensures that the C callstack remains in order, e.g., prevents returns "through" other callback frames. I'm thinking about an interface like here: int interpretEnter(int *cbID); - (Re-)Enters the interpreter. Different from interpret() in such that it creates an environment (via setjmp) to return to. Fills in the cbID with an ID that is used in the return call. int interpretExit(int cbID); - Returns from a previous call to interpretEnter() with the provided callback ID. Both of the above functions may fail - interpretEnter() would fail if for some reason the interpreter cannot be entered (no setjmp/longjmp support, or failure to allocate jmpbuf). interpretExit() would fail if the callback ID is not the last "matching" ID. Note that the above does NOT make any assumptions on the means by which the VM gets notified about the occurrence of the callback itself nor any arguments etc. It is up to the plugin to provide that information by its idiosyncratic means. Question: Does anyone have a problem with the above? I'm trying to design "just enough" so that projects like wxSqueak or others can cooperate without knowing too much about each other. Cheers, - Andreas

5 11

Inliner strangeness
by Andreas Raab 09 Jun '06

09 Jun '06

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

3 3

InterpreterProxy>>signed64BitIntegerFor: badly broken
by Andreas Raab 08 Jun '06

08 Jun '06

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? - Andreas PS. The primitive: TestPlugin>>testSigned64BitInt | oop | self export: true. interpreterProxy methodArgumentCount = 1 ifFalse:[^interpreterProxy primitiveFail]. oop := interpreterProxy stackValue: 0. oop := interpreterProxy signed64BitIntegerFor: (interpreterProxy signed64BitValueOf: oop). interpreterProxy failed ifFalse:[ interpreterProxy pop: 2 thenPush: oop. ].

2 2

Re: Keeping oops across primitives
by Andreas Raab 06 Jun '06

06 Jun '06

Cees De Groot wrote: > I'm hardly a VM hacker, but: > > On 6/6/06, Andreas Raab <andreas.raab(a)gmx.de> wrote: >> sqInt addToVmRoots(sqInt *newArray, sqInt newCount, sqInt *oldArray); > > why not oldCount as an argument? Or zero-terminated arrays for that matter? oldCount is irrelevant since the VM won't copy the contents of newArray; it will merely keep a reference to it (the array really is under control of the plugin). Therefore all we need is the reference to oldArray (this also goes for reallocating via realloc() - just remember the old pointer before you do that and pass it into the above to update the oop array). Why not NULL terminated? I'm planning on using NULL as the "undefined entry" in the oop array. Since this code is managed by some other C code that seems preferrable to nil (although the plugin could store nil just as well). But it probably will be valuable for the C code to be able to say "clear this entry" via storing NULL and having the VM skip this is fairly simple. Cheers, - Andreas

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev June 2006