Vm-dev May 2011

vm-dev@lists.squeakfoundation.org

36 participants
89 discussions

VM Maker: VMMaker-dtl.237.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 24 May '11

24 May '11

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.237.mcz ==================== Summary ==================== Name: VMMaker-dtl.237 Author: dtl Time: 23 May 2011, 11:38:51 am UUID: db716650-3b1b-4d54-9aba-6257a21a50a7 Ancestors: VMMaker-dtl.236 VMMaker 4.5.1 Convert primitive error reporting to use #primitiveFailFor: such that the successFlag variable is replaced with primFailCode (integer value, 0 for success, 1, 2, 3... for failure codes), consistent with oscog. Includes improved #failed, #successful, and #success: methods recoded for performance in C, yielding performance equivalent to previous implementation with successFlag. Changes were applied as follows: - Replaced all occurances of "successFlag := true" with "self initPrimCall", which initialize primFailCode to 0. - Replaced all "successFlag := false" with "self primitiveFail". - Replaced all "successFlag ifTrue: [] ifFalse: []" with "self successful ifTrue: [] ifFalse: []". - Updated #primitiveFail, #failed and #success: to use primFailCode rather than successFlag. - Removed successFlag variable.

1 0

VM Maker: VMMaker-oscog-IgorStasenko.67.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 24 May '11

24 May '11

Igor Stasenko uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-oscog-IgorStasenko.67.mcz ==================== Summary ==================== Name: VMMaker-oscog-IgorStasenko.67 Author: IgorStasenko Time: 24 May 2011, 4:22:13 am UUID: 99d89e06-acf0-4994-8967-c4af78940d70 Ancestors: VMMaker-oscog-MarianoMartinezPeck.66 - Ephemerons support for Cog. See http://code.google.com/p/cog/issues/detail?id=44 for image-side changes & tests.

1 0

[Ann] Ephemerons for Cog
by Igor Stasenko 24 May '11

24 May '11

I felt a bit hacky today and decided to implement Ephemerons. I tried to run it on both StackVM and Cog VMs, it seems to work fine (at least all 4 tests, which my brain were capable to produce, are green. ;) You can find the VM code on SqS/VMMaker in package: VMMaker-oscog-IgorStasenko.67 Also, i created a separate issue on Cog issue tracker to track it. http://code.google.com/p/cog/issues/detail?id=44 The implementation may contain a bugs. So, it needs review and testing. Now i would like all interested parties to give a feedback and help integrating it into our production images. -- Best regards, Igor Stasenko AKA sig.

1 0

Interpreter>>signed64BitValueOf: breaks the simulator
by Craig Latta 24 May '11

24 May '11

Hi again-- I assume I should be making entries in a bug database somewhere, but if I knew the details before I've forgotten them now, please remind me... :) Interpreter>>signed64BitValueOf: includes the line "szsqLong := self cCode: 'sizeof(sqLong)'", without an "inSmalltalk" equivalent. What should it be? Sorry for these rudimentary questions. (I'm sanity-checking the Spoon VM changes by connecting two systems together, one on MacOS and the other on win32 in the simulator.) thanks again, -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

2 3

There are still some problem with #become: in Cog
by Igor Stasenko 23 May '11

23 May '11

Segmentation fault Tue May 24 01:46:20 2011 C stack backtrace: 0 CogVM 0x00082e09 reportStackState + 121^@ 1 CogVM 0x0008304b sigsegv + 123^@ 2 libSystem.B.dylib 0x9514246b _sigtramp + 43^@ 3 ??? 0xffffffff 0x0 + 4294967295^@ 4 CogVM 0x0004076c becomewithtwoWaycopyHash + 3436^@ 5 CogVM 0x00040eb5 primitiveArrayBecomeOneWay + 37^@ 6 ??? 0x1c1eaf39 0x0 + 471772985^@ 7 CogVM 0x00074674 initStackPagesAndInterpret + 564^@ 8 CogVM 0x00088aa3 EventLoopEventHandler + 147^@ 9 HIToolbox 0x92cc8ecf _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1567^@ 10 HIToolbox 0x92cc8196 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 411^@ 11 HIToolbox 0x92cc7ff5 SendEventToEventTargetWithOptions + 58^@ 12 HIToolbox 0x92cfcc18 _ZL29ToolboxEventDispatcherHandlerP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv + 3006^@ 13 HIToolbox 0x92cc9320 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 2672^@ 14 HIToolbox 0x92cc8196 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 411^@ 15 HIToolbox 0x92ceaa07 SendEventToEventTarget + 52^@ 16 HIToolbox 0x92e73d2b ToolboxEventDispatcher + 86^@ 17 HIToolbox 0x92e73e63 RunApplicationEventLoop + 243^@ 18 CogVM 0x0008828f RunApplicationEventLoopWithSqueak + 239^@ 19 CogVM 0x000840ce main + 3838^@ 20 CogVM 0x000063d5 start + 53^@ 21 ??? 0x00000002 0x0 + 2^@ Smalltalk stack dump: 0xbff6466c M CompiledMethod(Object)>becomeForward: 492642732: a(n) CompiledMethod 0xbff64690 M CompiledMethod>setSourcePointer: 492642732: a(n) CompiledMethod 0xbff646ac M CompiledMethod>setSourcePosition:inFile: 492642732: a(n) CompiledMethod 0xbff646d4 M CompiledMethod>putSource:fromParseNode:inFile:withPreamble: 492642732: a(n) CompiledMethod 0xbff6470c I Trait(TraitBehavior)>addTraitSelector:withMethod: 492596428: a(n) Trait 0xbff64740 I [] in Trait(TraitBehavior)>updateMethodDictionarySelector: 492596428: a(n) Trait 0xbff64760 M OrderedCollection>do: 492621684: a(n) OrderedCollection 0xbff6478c I Trait(TraitBehavior)>updateMethodDictionarySelector: 492596428: a(n) Trait 0xbff647b8 I [] in Trait(TraitBehavior)>noteChangedSelectors: 492596428: a(n) Trait 0xbff647d8 M [] in IdentitySet(Set)>do: 492617636: a(n) IdentitySet 0xbff647fc M Array(SequenceableCollection)>do: 492620720: a(n) Array 0xbff64818 M IdentitySet(Set)>do: 492617636: a(n) IdentitySet 0xbff64840 I Trait(TraitBehavior)>noteChangedSelectors: 492596428: a(n) Trait 0xbff64868 I Trait(TraitBehavior)>applyChangesOfNewTraitCompositionReplacing: 492596428: a(n) Trait 0xbff64890 I Trait(TraitDescription)>applyChangesOfNewTraitCompositionReplacing: 492596428: a(n) Trait 0xbff648b8 I Trait>applyChangesOfNewTraitCompositionReplacing: 492596428: a(n) Trait 0xbff648e0 I Trait(TraitBehavior)>setTraitComposition: 492596428: a(n) Trait 0xbff64910 I Trait class>named:uses:category:env: 473441580: a(n) Trait class 0xbff64944 I Trait class>named:uses:category: 473441580: a(n) Trait class 0xbff64974 I TraitCompositionTest(TraitsTestCase)>createTraitNamed:uses: 489548004: a(n) TraitCompositionTest 0xbff6499c M TraitCompositionTest>testProvidedMethodBindingsWithConflicts 489548004: a(n) TraitCompositionTest 0xbff649b4 M TraitCompositionTest(TestCase)>performTest 489548004: a(n) TraitCompositionTest 0xbff649cc M [] in TraitCompositionTest(TestCase)>runCase 489548004: a(n) TraitCompositionTest With traits there could be some caveats, since they are manipulating with classes and methods.. and so.. it could be that they could install a method, which not belongs to the class, or something else. -- Best regards, Igor Stasenko AKA sig.

1 0

VM Maker: VMMaker-dtl.236.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 23 May '11

23 May '11

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.236.mcz ==================== Summary ==================== Name: VMMaker-dtl.236 Author: dtl Time: 20 May 2011, 10:52:22 am UUID: e31236d5-2803-45b6-abde-1a2a423dabd0 Ancestors: VMMaker-dtl.235 VMMaker 4.5.0 Move most primitives from class Interpreter into new superclass InterpreterPrimitives, as per oscog. Reduces clutter in Interpreter, and positions InterpreterPrimitives to be shared among various interpreter implementations. All primitive implementations are currently from Interpreter (further reconciliation to follow). With this update, the generated interp.c source is identical to the previous VMMaker except for the ordering of instance variables (i.e. the generated C source is functionally identical). Several methods were moved from Interpreter to ObjectMemory as part of this refactoring. Some class and instance variables were moved into InterpreterPrimitives; these will probably go away as oscog changes are adopted. A number of class variables were moved from Interpreter to VMObjectIndices. To do: Adopt and/or reconcile oscog changes to InterpreterPrimitives such that StackInterpreter and Interpreter share common base primitives.

2 1

VM Maker: CMakeVMMaker-StasenkoIgor.104.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 23 May '11

23 May '11

Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz ==================== Summary ==================== Name: CMakeVMMaker-StasenkoIgor.104 Author: StasenkoIgor Time: 16 May 2011, 10:33:56 am UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b Ancestors: CMakeVMMaker-IgorStasenko.103 workaround the MultiByteCrapStream, which converting line endings twice on windows.

7 20

Interpreter>>primitiveNewWithArg breaks the simulator
by Craig Latta 23 May '11

23 May '11

Hi-- Mm, looks like a bunch of 64-bit fun is in store for me. :) Interpreter>>primitiveNewWithArg includes: *** self isDefinedTrueExpression: 'SQ_IMAGE64 && SQ_HOST64' inSmalltalk: [size := self positive32BitValueOf: self stackTop] comment: 'permit large object allocation on 64 bit image and host' ifTrue: [size := self positive64BitValueOf: self stackTop] ifFalse: [size := self positive32BitValueOf: self stackTop] *** The "in Smalltalk" part doesn't answer a Boolean. What should it be? thanks again, -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

2 1

undeclared variable "pluginClass" in VMPluginCodeGenerator
by Craig Latta 23 May '11

23 May '11

Hi-- I assume this has been discussed and dealt with already, but if not... During integration of the Spoon VM changes with a recent VMMaker (VMMaker-dtl.227), I noticed an undeclared variable "pluginClass" in VMPluginCodeGenerator>>isTypePointerToStruct:, written by Eliot. -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

1 0

What happens with named primitives in CM ?
by Mariano Martinez Peck 23 May '11

23 May '11

Hi folks. I was inspecting for example the CM of Integer >> #bitAnd: and the first literal is an array like this: #(#LargeIntegers #primDigitBitAnd 0 17) I understand the first and the second elements, but I don't the third and the fourth. What are they? (0 and 17) because then even seem to change their value. I am asking because I am serializing CompiledMethod and then at materialization time I am putting just two zeros for the moment. But I am not sure what they mean. Thanks in advance, -- Mariano http://marianopeck.wordpress.com

2 4

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2011