Vm-dev October 2010

vm-dev@lists.squeakfoundation.org

27 participants
60 discussions

[eliot.miranda@gmail.com: Re: VM Maker: VMMaker-dtl.189.mcz]
by David T. Lewis 06 Oct '10

06 Oct '10

Forwarding to the list with permission. Eliot provides some explanations that may be of general interest. Dave ----- Forwarded message from Eliot Miranda <eliot.miranda(a)gmail.com> ----- Date: Wed, 6 Oct 2010 11:30:15 -0700 Subject: Re: VM Maker: VMMaker-dtl.189.mcz From: Eliot Miranda <eliot.miranda(a)gmail.com> To: "David T. Lewis" <lewis(a)mail.msen.com> On Wed, Oct 6, 2010 at 5:35 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Tue, Oct 05, 2010 at 10:07:25PM -0700, Eliot Miranda wrote: > > Hi David, > > > > On Tue, Oct 5, 2010 at 9:44 PM, David T. Lewis <lewis(a)mail.msen.com> > wrote: > > > > > Hi Eliot, > > > > > > Apologies if this is a duplicate message (a previous message seems to > > > have disappeared), but attached are the changes for loading a Cog > > > image into a standard VM. > > > > > > I can load a Cog image into a standard VM, save the image in old > > > format, and load that saved image back into Cog. Float values > > > are preserved throughout. This should open the possibility of > > > developing images with Cog that may later need to be loaded into > > > a standard VM. > > > > > > > this is cool. But why not adopt platform floats in the standard VM? > It's > > faster. > > > > I don't know actually, have not even looked at it. But if it's anything > non-trivial, my time would be better spent on easing the transition > to Cog, which will give much larger performance benefits ;) > > One thing I'd like to do is work through the list of plugins, getting > everything as consistent and up to date as possible. There are plugins > in oscog that are missing things from the main branch and vice versa, > and a few cases where merging may be needed. I'll probably be bothering > you with occasional emails on this topic. > > You had mentioned a couple of things related to primitive error return > and function lookup that we need to add into the traditional VM. I'll > probably be working on some of this on Friday, so if you can give me > some pointers as to what needs to be done, I'll see if I can take care > of it. > You could do it but so could I, and I've already done it. Here's what to do, without specifying who does it. *Prim Fail Code* Get an image with Lukas' latest rewrite engine from the refactoring browser (AST-Core & AST-Semantic from squeaksource.com/rb). Then rewrite successFlag => self successful successFlag := expr => self successful: expr then eliminate successFlag and replace it with primFailCode. Whereever successFlag := true. is done to prepare for primitive invocation (internalExecuteNewMethod et al) replace successFlag := true with self initPrimCall and then use the following methods to test for success/failure initPrimCall "Set the failure code/success flag in preparation for calling a primitve. If primFailCode is non-zero a primitive has failed. If primFailCode is greater than one then its value indicates the reason for failure. Override to disable the - for the jit - cumbersome stack balance checking code." <inline: true> primFailCode := 0 failed <api> ^primFailCode ~= 0 primitiveFail "Set general (unspecified) primitive failure. Don't overwrite an error code that has already been set." "Use returnTypeC: #sqInt because that's the way it is defined in sq.h. Use no explicit return so that Slang doesn't fail an inlin ingtype-check when a primitive with return type void uses ^self primitiveFail to exit." <returnTypeC: #sqInt> primFailCode == 0 ifTrue: [primFailCode := 1] primitiveFailFor: reasonCode "Set specific primitive failure. N.B. primitiveFailFor: PrimNoErr is expected to clear the primFailCode." <api> ^primFailCode := reasonCode success: successBoolean "Set the state of the primitive failure code/success flag, iff successBoolean is false. If primFailCode is non-zero a primitive has failed. If primFailCode is greater than one then its value indicates the reason for failure." "Use returnTypeC: #sqInt because that's the way it is defined in sq.h. Use no explicit return so that Slang doesn't fail an inlin ingtype-check when a primitive with return type void uses ^self success: false to exit." <returnTypeC: #sqInt> <inline: true> successBoolean ifFalse: ["Don't overwrite an error code that has already been set." primFailCode == 0 ifTrue: [primFailCode := 1]] successful "Answer the state of the primitive failure code/success flag. If primFailCode is non-zero a primitive has failed. If primFailCode is greater than one then its value indicates the reason for failure." <inline: true> ^primFailCode == 0 Object Memory => objectMemory refactoring Look at the division of labour in the Cog VMMaker between ObjectMemory, NewObjectMemory et al and StackInterpreter CoInterpreter et al for object-emory related selectors. Basically we want to replicate the movement of methods between the two. I've been tweaking this for a whole so its best to copy what I've done in Cog rather than try and come up with the division anew. Then once methods have been moved to the right place use the rewrite engine to replace 'self `@method: ``@args' with 'objectMemory `@method: ``@args' (the rewrite engine is soooo cool) for all methods in Interpreter that are implemented by ObjectMemory. You'll need to use the Cog Slang to get objectMemory elided in translation, which you address here: I'm also really interested in what you have done for the code generator > to support object memory as an instance variable. I wonder if I can > do something similar to mix class MemoryAccess (slang version of > sqMemoryAccess.h) into an object memory (this is personal interest, > I have no intention of adding it to the VMMaker package per se). > So in the Cog VMMaker look at senders/implementors of isNonArgumentImplicitReceiverVariableName: and shouldExcludeReceiverAsFirstArgument:. There are a couple of things going on here One is that when objectMemory is in an inst var sends to objectMemory need to have objectMemory elided just as sends to self or interpreterProxy have the receiver elided (or replaced by interpreterProxy->foo). The other is that struct types such as CogAbstractInstruction need to keep self so that e.g. CogAbstractInstruction>>addDependent: anInstruction <var: #anInstruction type: #'AbstractInstruction *'> <returnTypeC: #'AbstractInstruction *'> dependent notNil ifTrue: [anInstruction dependent: dependent]. ^dependent := anInstruction is translated as static AbstractInstruction * addDependent(AbstractInstruction * self_in_addDependent, AbstractInstruction *anInstruction) { if (((self_in_addDependent->dependent)) != null) { (anInstruction->dependent = (self_in_addDependent->dependent)); } return (self_in_addDependent->dependent) = anInstruction; } There's other machinery to support these struct types (subclasses of VMStructType); primarily see senders/implementors of isAccessor: isStructAccessor and transformToStructClassMethodFor:. BTW, I think mixing class MemoryAccess into ObjectMemory is an excellent thing to do, and you should absolutely think of adding it to VMMaker. One of the things I don't like about thr Cog structure right now is that there is no sharing between the simulators. Basically Interpreter, StackInterpreter, CoInterpreter, NewObjectMemory *and* NewCoObjectMemory all have simulator subclasses even though there is huge commonality between the three interpreter simulators and between the two ObjectMemory simualtors (note that once we refactor Interpreter to use the objectMemory inst var then ObjectMemory will also need a simulator). One alternative would be to push the simulation code up into superclasses of ObjectMemory and InterpreterPrimitives, e.g. into VMClass. I've already done that with things like oop:isGreaterThan:. Another alternative is to put it into the classes itself and use the <doNotGenerate> pragma to avid its generation, but that can get quite cluttered. But neither of these approaches copes with LSB vs MSB issues, for which we either use an VMBIGENDIAN ifTrue:ifFalse: or subclasses. best Eliot > Dave > > ----- End forwarded message -----

1 0

VM Maker: VMMaker-Igor.Stasenko.37.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 06 Oct '10

06 Oct '10

Igor Stasenko uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-Igor.Stasenko.37.mcz ==================== Summary ==================== Name: VMMaker-Igor.Stasenko.37 Author: Igor.Stasenko Time: 6 October 2010, 8:36:31 am UUID: 6fcf9560-ff1b-fc47-9e20-044051722a5b Ancestors: VMMaker-oscog.36 integration of finalization enhancements for Cog VM (ignore the Interpreter changes, when merging)

1 0

VM Maker: VMMaker-Igor.Stasenko.37.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 06 Oct '10

06 Oct '10

6 6

Mix & match plugin and interpreter in Cog
by Igor Stasenko 06 Oct '10

06 Oct '10

Hello, in order to avoid overrides to CoInterpreter, i created a subclass - NBCoInterpreter, where i put overridden methods. Now how i could tell that CogNativeBoostPlugin is fine for including when generating code using NBCoInterpreter, but not CoInterpreter, so it won't be mistakenly included in standard Cog VM build? -- Best regards, Igor Stasenko AKA sig.

2 5

VMMaker-oscog.36.mcz - MC says Interpreter changed
by Igor Stasenko 06 Oct '10

06 Oct '10

Hello, i _loaded_ the new version of VMMaker into image, and then simply press 'changes' in MC, and it shows that Interpreter class is changed. Looks like a side effects of some class initialization. -- Best regards, Igor Stasenko AKA sig.

1 0

Cog crash on linux
by Igor Stasenko 06 Oct '10

06 Oct '10

uname -a Linux sig-desktop 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux The image i run was not Cog-ready: sig@sig-desktop:~/cogvm$ ./squeak ~/squeak/NativeBoost.image Segmentation fault Smalltalk stack dump: 0xbfa58d68 M GradientFillStyle>scaledAlphaMix:of:with: 2039648948: a(n) GradientFillStyle 0xbfa58dbc M [] in GradientFillStyle>computePixelRampOfSize: 2039648948: a(n) GradientFillStyle 0xbfa58ddc M SortedCollection(OrderedCollection)>do: 2039649272: a(n) SortedCollection 0xbfa58e14 I GradientFillStyle>computePixelRampOfSize: 2039648948: a(n) GradientFillStyle 0xbfa58e38 I [] in GradientFillStyle class>initPixelRampCache 2012018000: a(n) GradientFillStyle class 0xbfa58e68 M LRUCache>at: 2016558228: a(n) LRUCache 0xbfa58e84 M GradientFillStyle>pixelRamp 2039636440: a(n) GradientFillStyle But this image was not Cog-ready. Okay, i copied a cog-ready image: sig@sig-desktop:~/cogvm$ ./squeak ./Squeak4.2-10382-alpha.image Segmentation fault sig@sig-desktop:~/cogvm$ What's interesting, that its have about 70% probability to crash almost instantry, it just blinking a newly-created host window, and then ending up with segfault. In another 30% of cases its not crashing immediately and opens a host window. But once i try do something, like resizing the window, it crashing. And what is bad, that i can't even get a stack dump. This is all it prints: sig@sig-desktop:~/cogvm$ ./squeak ./Squeak4.2-10382-alpha.image Segmentation fault sig@sig-desktop:~/cogvm$ ./squeak ./Squeak4.2-10382-alpha.image Segmentation fault sig@sig-desktop:~/cogvm$ ./squeak ./Squeak4.2-10382-alpha.image I tried multiple couple different images: sig@sig-desktop:~/cogvm$ ./squeak ./PharoCore-1.2-12159.image Segmentation fault sig@sig-desktop:~/cogvm$ ./squeak ./PharoCore-1.2-12159.image Segmentation fault sig@sig-desktop:~/cogvm$ ./squeak ./PharoCore-1.2-12159.image Segmentation fault sig@sig-desktop:~/cogvm$ ./squeak ./PharoCore-1.2-12159.image Segmentation fault it starts, but then once i try to do something like clicking a mouse in window, it crashing. I am also tried to use gdb to find where the problem , after attaching to running process: gdb -p 25413 and continuing: (gdb) cont Continuing. It is then at some moment prints following: Cannot find user-level thread for LWP 25416: generic error (gdb) bt Target is executing. (gdb) info threads 2 Thread 0x77857b70 (LWP 25416) (running) * 1 Thread 0xb78976c0 (LWP 25413) (running) At that moment VM no longer responsive , while gdb still thinks that it running.. weird. -- Best regards, Igor Stasenko AKA sig.

2 4

RE: To FFI or not to FFI
by Schwab,Wilhelm K 05 Oct '10

05 Oct '10

Bert, In saying that "port the vm and everything just works" you appear to be ignoring that the plugins have to be ported too. Whether one tweaks and debugs(!!) Smalltalk or C, there will be things to port and fix. I for one would much rather work out the details of a stubborn platform dependency in readily changed and debugged Smalltalk than C hidden away in the vm. Where I get worried is with an apparent general desire to do everything in Smalltalk when a shared library might be/is the answer. Bill Bert Freudenberg bert at freudenbergs.de Fri Oct 1 14:31:52 UTC 2010 We are not talking about optional add-ons. For that, yes, FFI is the quick-and-dirty solution, go ahead and have fun wrapping every library on the planet. What I am objecting to is the zealous quest to move core functionality out of proper plugins to the image, be it using FFI or Alien or any other generic callout mechanism. Being able to take an image and run it anywhere without having to worry about the platform is a Good Thing. Once John ported the Squeak VM to iOS, Etoys *just worked*. That's the power our VM abstraction gives us. Also, the whole Squeak sandbox security model depends on the VM being able to prevent code in the image to do damage. There is no way to do that if you let the image use FFI. Do you want my Etoys project to wipe out your hard disk? I didn't think so. There is another benefit to plugins that encapsulate platform capabilities: Once the interface has been written, you only need to know C, not so much Smalltalk, to port it to another platform. If the primitive interface has been well-designed this is much easier than doing it in Smalltalk. Plus, it is much simpler to get help from platform experts if they can see the C code.

11 14

how to map bytecodes to methods?
by Mariano Martinez Peck 05 Oct '10

05 Oct '10

Hi. I am new with all these stuff. My problem is how to map bytecodes numbers to methods. For example, if in a method I send #class and see the bytecodes I can see it has a "C7", which in decimal is 199. If I see Interpreter class >> initializeBytecodeTable then in 199 I see #bytecodePrimClass which is correct. Now....I want to go in the OTHER direction. For example, I have changed something in #bytecodePrimValueWithArg and I would like to know WHICH method from the image side, generates that bytecode. Ok, sometimes it is intuitive, but sometimes more or less... Thanks Mariano

2 1

Fwd: [Vm-dev] RE: To FFI or not to FFI
by Colin Putney 05 Oct '10

05 Oct '10

Oops, forgot to reply to the list. ---------- Forwarded message ---------- From: Colin Putney <colin(a)wiresong.com> Date: Tue, Oct 5, 2010 at 9:28 AM Subject: Re: [Vm-dev] RE: To FFI or not to FFI To: stephane ducasse <stephane.ducasse(a)gmail.com> On Tue, Oct 5, 2010 at 12:10 AM, stephane ducasse <stephane.ducasse(a)gmail.com> wrote: > Your point is really true and I think that indeed this hampers eliminating the truck factor. > The fact that they are three to use it is by no way a good argument. This > by construction shows my fears. Well, I wasn't making a point, just asking a (non-rhetorical) question. :-) I think everyone would agree that making the VM more accessible would be a good thing; I'm just thinking about how to go about it. Colin

1 0

VM Maker: VMMaker-oscog.36.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 05 Oct '10

05 Oct '10

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-oscog.36.mcz ==================== Summary ==================== Name: VMMaker-oscog.36 Author: eem Time: 4 October 2010, 7:15:15 am UUID: 79f2435a-ad54-4d89-be04-cd4efaad1ede Ancestors: VMMaker-oscog.35 LargeIntegersPlugin minor simplification to digitSubLarge:with: Simulator: Fix SmartSyntaxPluginSimulator; the receiver: spec applies to the receiver, not the result, bozo!! Fix simulation of 64-bit integer arithmetic which didn't truncate the result to 64 bits, hence failing to fail for results that overflow 64 bits. Allow simulator to avoid booleanCheat: for comparing bytecode traces obtained by runSimulated:contextAtEachStep:

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev October 2010