Vm-dev December 2010

vm-dev@lists.squeakfoundation.org

42 participants
109 discussions

where to commit?
by Eliot Miranda 31 Dec '10

31 Dec '10

Hi All, I'm sitting on a new Cog code generator which is ready to release as soon as I can find a repository to commit to. www.squeakvm.org is down (permanently?). I'm not an owner of squeakvm.googlecode.com (anyone?). I'd rather not use the gitorious site. a) can an owner add me as an owner to squeakvm.googlecode.com? b) should the following work? (it fails with abort: error: Operation timed out) hg manifest -R https://squeakvm.googlesource.com/hg/ A faster Cog VM will ensure. best Eliot

6 15

VM Maker: CMakeVMMaker-Igor.Stasenko.9.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 30 Dec '10

30 Dec '10

Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-Igor.Stasenko.9.mcz ==================== Summary ==================== Name: CMakeVMMaker-Igor.Stasenko.9 Author: Igor.Stasenko Time: 30 December 2010, 10:32:07 am UUID: 02c1b86d-f55b-413d-afe2-f23db6a852cd Ancestors: CMakeVMMaker-Igor.Stasenko.8 added __LITTLE_ENDIAN definition for FloatMathPlugin

1 0

VM Maker: VMMaker-oscog.40.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 30 Dec '10

30 Dec '10

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-oscog.40.mcz ==================== Summary ==================== Name: VMMaker-oscog.40 Author: eem Time: 30 December 2010, 12:37:41 pm UUID: 637db40c-33c6-4263-816e-1b8cc19e3c99 Ancestors: VMMaker-eem.685, VMMaker-oscog.37 New StackToRegisterMappingCogit that produces significantly more efficient and more compact code. Benefits vary widely based on work-load. e.g on 2.66 GHz Core i7 MacBook Pro SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 192 - 691 / 6.91 -72% SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127 sends/sec' StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; 128157989 sends/sec' 931756141 - 753495217 / 7534952.17 -24% 128157989 - 64769127 / 647691.27 -98% SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no transcript StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no transcript) 43406 - 47013 / 470.13 -7.67234594686576 Fix bug in pc mapping in blocks. An ^-return in a block has both a pc map entry and a CallRT map entry because of the call to ceNonLocalReturn. Hence the bytecode descriptors need to reflect this. The old code didn't know this and hence pc mapping was wrong for pcs following an ^-return in a block. Non-threaded callbacks. Implement legacy sendInvokeCallback:Stack:Registers:Jmpbuf: style. Provide a more general new style that avoids 64-bit limitations. VMCallbackContext includes all the necessary state for a callback, so the new arg count can be 1 (and is in interp.h). New sendInvokeCallbackContext will work with either old Alien class>invokeCallback:stack:registers:jmpbuf: entry-point or new Alien class>invokeCallbackContext:. Other fixes described in the history.

1 0

can someone add me to squeakvm.googlecode.com?
by Eliot Miranda 30 Dec '10

30 Dec '10

SLSIA TIA eem

1 0

VM Maker: CMakeVMMaker-Igor.Stasenko.8.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 30 Dec '10

30 Dec '10

Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-Igor.Stasenko.8.mcz ==================== Summary ==================== Name: CMakeVMMaker-Igor.Stasenko.8 Author: Igor.Stasenko Time: 30 December 2010, 3:55:56 am UUID: 546ef2e8-cc34-4edb-ade1-f3adc891c415 Ancestors: CMakeVMMaker-Igor.Stasenko.7 - added a common class for generating source + cmake configs (CMakeGenScripts) - added a StackInterpreterMacOSConfig , but probably it would be better to not subclass it from CogMacOSConfig, since CogMacOSConfig using 'Mac OS' platform dir, and should die eventually.

1 0

Re: [squeak-dev] A Bootstrap Compiler
by Eliot Miranda 30 Dec '10

30 Dec '10

Hi Yoshiki, On Tue, Dec 28, 2010 at 2:19 AM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > Hi, > > We've been playing with John's MicroSqueak and it occured to me that > having a bytecode compiler that is implemented outside of Squeak opens > some possibilities, such as generate a growable image file from all > text files, or make deep changes to the system without shooting > yourself. > > I wrote a longer explanation so if you are interested, please go to: > > https://github.com/yoshikiohshima/SqueakBootstrapper > > and check it out. > I simply don't see the benefit of putting energy into other languages. I see the benefit of a textual bootstrap. But why is it worth-while implementing that in C instead of Smalltalk? If Smalltalk is more productive (which it is) then writing such a bootstrap in C is a waste of effort, reinvents several wheels at considerable expense and produces an artifact that is less flexible, less extensible, less useful than implementing the same functionality in Smalltalk. On the other hand, as Andreas suggests, trying to implement something using the simulator looks to be really powerful. Recent;y I've been playing tangentally in this area. In recent days I've produced a new code generator for Cog that has some useful speedups (Compiler recompileAll ~ 9% faster, benchFib 2x). To test the code generator I needed to check stack depths at various points in JIT compilation and execution of the JITted code. I have a Smalltalk class StackDepthFinder that answers the stack depths for each bytecode of a method. By adding two classes VMObjectProxy and VMCompiledMethodProxy I could apply StackDepthFinder to methods in the simulator's heap and hence derive stack depths for any method in the simulators image. To test the JIT it was also convenient to be able to JIT methods in my work image, synthesised test cases etc, not just methods in the simulated image. Again a facade class allows the simulator to JIT any method in my work image. This worked well and was easy to implement. Extending in this direction seems straight-forward. One starts up wit a simulator and an empty heap and bootstraps objects into that heap, using whatever bytecode set and object format one chooses. One can test the image using the simulator which should be quite fast enough if the image is a small kernel. All the implementation is useful and adds to the simulator/VMMaker ecosystem. All the code is Squeak and can reuse substantial parts of the system. Seems like a win to me. I think I'll take this approach in implementing the new object format. It could be a new backend to MicroSqueak. cheers Eliot Thank you! > > -- Yoshiki > >

5 4

Re: [squeak-dev] Re: [4.2] tests status
by David T. Lewis 29 Dec '10

29 Dec '10

On Sun, Dec 26, 2010 at 08:16:22AM +0100, Andreas Raab wrote: > On 12/24/2010 9:35 PM, David T. Lewis wrote: > >On Fri, Dec 24, 2010 at 03:41:23PM -0300, Jecel Assumpcao Jr. wrote: > >>Ken G. Brown wrote on Wed, 22 Dec 2010 23:19:45 -0800 > >>>I think too, that it would be good to coordinate with Matthew F. > >>>To be sure the Croquet stuff is operational in 4.2. > >> > >>Yes, this was actually mentioned in the last meeting report - > >> > >>http://squeakboard.wordpress.com/2010/12/21/meeting-report-for-december- > >>21-2010/ > >> > >>If I understood correctly, he will continue to track Trunk and doesn't > >>feel that an incomplete merge in 4.2 will be a problem. He did mention > >>the "FloatMath plugin issue" and that it would be good to have that > >>solved in 4.2, but I have not been paying attention to this discussion. > > > >I think that the "FloatMath plugin issue" is Mantis 0007583: Float does > >not use FloatMathPlugin for bit-consistent float math across platforms. > > > > http://bugs.squeak.org/view.php?id=7583 > > I went ahead and pushed the changes. They do look reasonable to me but > please everyone give it a shot and run all the float tests to ensure it > works on your favorite platform as well. In short, if all the tests in > KernelTests-Numbers pass, we're good, if any fail, please report back > with details. > > Cheers, > - Andreas (cc to vm-dev list) I have found an additional issue with the FloatMath updates. When running on a VM compiled for 64 bits, an updated trunk image hangs up with no input event processing and no display updates. This is on a Linux VM compiled with no optimization (CFLAGS='-g -m64 -O0). The problem is related to Float>>fractionPart. If this method is reverted to the prior version, or if the FloatMathPlugin is not present, the image no longer hangs. The primitive in question is FloatMathPlugin>>primitiveFractionalPart which presumably has a bug related to pointer size. The bug is exposed by compiling with 64 bit pointers, and the updated trunk image will hang up if the primitive is being called by Float>>fractionPart. The FloatMathPlugin>>primitiveFractionalPart method looks fine (variables all declared correctly). The error occurs within the __ieee754_modf(rcvr, &trunc) function call, which produces completely bogus results when compiled -m64. This function is implemented as modf() in fdlibm. A stand-alone C test program confirms that the bug is in the library function itself. Presumably this bug would affect Mac VMs compiled for 64-bits, and I think there are a number of these in circulation (though I do not know if they include the FloatMathPlugin). Dave

2 3

VM Maker: CMakeVMMaker-Igor.Stasenko.7.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 29 Dec '10

29 Dec '10

Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-Igor.Stasenko.7.mcz ==================== Summary ==================== Name: CMakeVMMaker-Igor.Stasenko.7 Author: Igor.Stasenko Time: 29 December 2010, 3:50:26 am UUID: 8c273498-1297-448a-be50-98826312ef9e Ancestors: CMakeVMMaker-Igor.Stasenko.6 - added support for building external plugins. - external plugins are _not_ bundled but placed as a .dylib in app bundle's Resources directory.

3 5

FloatMathPlugin crashes the VM if compiled with gcc optimization
by David T. Lewis 29 Dec '10

29 Dec '10

VM builders: Recent updates in Squeak trunk expose an issue with the FloatMathPlugin. This plugin should be built with compiler optimization turned off, otherwise the plugin can crash the VM. The Mantis report is at http://bugs.squeak.org/view.php?id=7592 and the discussion on squeak-dev is at http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156132… Although this has not been verified on all platforms, the working assumption should be that optimization must be turned off for FloatMathPlugin when using gcc. Dave

5 11

VM Maker: VMMaker-dtl.213.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 28 Dec '10

28 Dec '10

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.213.mcz ==================== Summary ==================== Name: VMMaker-dtl.213 Author: dtl Time: 28 December 2010, 2:06:59 am UUID: f2524f34-cfcb-46ea-80b6-81402f9a875f Ancestors: VMMaker-dtl.212 VMMaker 4.4.4 Add FilePlugin>>primitiveFileStdioHandles adapted from oscog. Reference Mantis 0007591: Add #primitiveFileStdioHandles to standard VM Notes r.e. adopting the oscog implementation of primitiveFileStdioHandles: Cog primitive uses "interpreterProxy topRemappableOop" which is defined for VM_PROXY_MINOR > 9 but standard VM support code is at VM_PROXY_MINOR 8 (Cog is at VM_PROXY_MINOR 11). Work around this by popping and pushing the result array rather than using topRemappableOop. Cog uses primitive failure return codes not yet supported in the interpreter VM. The primitive return codes need to be adopted in standard VM but this is not yet done.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev December 2010