Hi All,
it gives me great pleasure to announce that the Teleplace Cog VMs are now available. Huge thanks to all at Teleplace who have given me the opportunity to build Cog and release it as open source, been willing guinea pigs braving its bugs, and providing indispensable participation in getting Cog to its current state. Huge thanks are also due to the original Back To The Future team whose VMMaker Cog extends to write the VM, and to Peter Deutsch from whom I've taken many ideas.
This release contains two VMs. The Stack VM, is a cross-platform interpreter that uses context-to-stack mapping to achieve modest performance gains. The Cog VM is a just-in-time compiler that currently supports only x86 that builds upon the Stack VM to achieve substantial performance improvements. The release is in the form of a Monticello package containing the VMMaker source and a tarball containing the platform sources, the generated sources and a Squeak 4.1 image containing the VMMaker sources. Download both at
http://ftp.squeak.org/Cog/VMMaker-oscog.11.mcz
http://ftp.squeak.org/Cog/OpenSourceCog.tar.gz
Cog VMs:
The Cog VMs are Squeak/Croquet VMs that run closure Squeak/Croquet/Pharo/Cuis images. The VMs support existing plugin source but will require plugins to be recompiled as the VM_PROXY_MAJOR plugin api has been extended.
This release contains two distinct VMs, the StackInterpreter and the Cogit. The StackInterpreter is a fully-portable plug-in replacement for the current closure Squeak VMs and images. The Stack VM uses context-to-stack mapping and a somewhat improved garbage collector to achieve modest but useful performance gains in the 10% to 15% range. The StackInterpreter is intended to supersede the Squeak VM on platforms where the Cogit cannot be used. The Cogit extends the StackInterpreter with a just-in-time compiler that uses aggressive inline caching techniques to deliver substantial performance gains in the 3x to 15x range, depending on benchmark. The Cogit currently supports only x86 and the floating-point primitives and parts of the platform support code depend on SSE2. I hope members of the community will attempt to port it, e.g. to ARM, PowerPC and x86-64. The Cogit (excuse the pun) is so named because it is both an interpreter and a JIT, choosing not to generate machine code for large methods, interpreting them instead, the default policy being not to JIT methods with more than 60 literals.
The Cog VM requires a few minor image changes all in image/NecessaryImageChangesForCogToWork.1.cs. The JIT's machine-code SmallInteger primitives insist on a SmallInteger receiver so the primitives in LargePositiveInteger = ~= bitAnd: bitOr: butShift: and bitXor: cannot be used and these methods must be deleted. The Cogit inlines the address of the Character instance table, Smalltalk specialObjectsArray at: 25, into the machine-code at: primitive for faster ByteString>>at: and so the table cannot be rebuilt in SmalltalkImage>>recreateSpecialObjectsArray. The new version preserves the existing table. Both VMs maintain floats in platform order to ease implementation of machine code floating-point primitives, and hence internally are in little-endian order instead of big-endian in current Squeak images. While the VMs convert float order automatically on load they do require special accessing primitives Float>>basicAt: & Float>>basicAt:put: that undo the reversal and answer Float contents in big-endian order so that e.g. Float>>hash is unchanged. The methods assume these primitives can fail, allowing the code to be used on current Squeak VMs.
The image/VMMaker-Squeak4.1.image is a Squeak 4.1 image, runnable with the current Squeak VMs, that contains these changes, and can hence also be run with a Cog VM. But beware, once an image has been saved on Cog it cannot be run by an existing Squeak VM, because existing VMs cannot undo the Float order change.
Platform Subsystem:
Most of the platform subsystem is unchanged but there are some important changes that need description. The biggest change is the heartbeat and the clock in platforms/unix/vm/sqUnixHeartbeat.c and platforms/win32/vm/sqWin32Heartbeat.c. The Cog VMs avoid the slow and variable interruptCheckCounter, folding the event check into the stack overflow check on frame build. The heartbeat, typically 500Hz or 1KHz, changes the stackLimit to a value that will always fail. On the next frame building send the VM will enter stack overflow handling that, as a side effect, will also check for events. This is more efficient than the update of interruptCheckCounter and much more regular. If one is running code that executes long-running primitives (e.g. large integer arithmetic) the counter approach will result in too low an interrupt check frequency, and conversely if one is running normal code the interrupt check frequency can be very high.
The heartbeat also maintains a 64-bit microsecond clock, UTC microseconds from 1901, from which the backward-compatible millisecond and second clocks are derived. Primitives exist to answer UTC microseconds and local microseconds. Updating the clock in the heartbeat results in a 1 or 2 millisecond resolution but avoids the cost of accessing the OS time on every prim tie which we've found important for performance at Teleplace. The 64-bit microsecond clocks provide a unified time basis and eliminate wrapping (for the next 54,000 years at least). I hope community images will move to these clocks. It's worked well in VisualWorks.
Another significant change is in the external semaphore table support code. This is now lock-free at the cost of having to specify a maximum number of external semaphores at start-up (default 256). The support code for the lock-free data structures are processor-specific and is currently implemented only for x86 and gcc-compatible compilers; see platforms/Cross/vm/{sqAtomicOps.h,sqMemoryFence.h}.
There is also improved crash reporting code that prints a primitive log and a C backtrace in addition to the Smalltalk backtrace. See platforms/Mac OS/vm/sqMacMain.c, platforms/unix/vm/sqUnixMain.c, platforms/win32/vm/sqWin32Intel.c & platforms/win32/vm/sqWin32Backtrace.c.
Finally there is support for the QVMProfiler, a pc-sampling profiler for profiling at the VM level. See platforms/unix/vm/sqUnixVMProfile.c and platforms/win32/vm/sqWin32VMProfile.c. The profiler itself is in the VMMaker image described below in Qwaq-VMProfiling.
There are also changes to do with Teleplace-specific extensions to the HostWindowPlugin but these are not essential to Cog.
VMMaker and Slang:
The image/VMMaker-Squeak4.1.image Squeak 4.1 image contains the complete Cog VMMaker with necessary support code for simulation. This image was used to generate the sources in the src and stacksrc directories.
Cog's VMMaker is substantially revised and extended from the current VMMaker. It supports multiple classes, not just Interpreter and superclasses, because both context-to-stack mapping and the Cogit are too complex to write monolithically. Classes can specify ancilliaryClasses and ancilliaryStructClasses, such as CoInterpreterStackPage, CogMethod and CogAbstractInstruction. The Monticello package version is included in the header of all generated files and constitutes the version stamp for generated code. Code is generated in sorted order so that minor changes in the Smalltalk source produce correspondingly minor changes in the generated code. The gnuification step is built-in to VMMaker. No effort has been made to maintain 64-bit compatibility. Apologies, this was unaffordable.
The VMMaker generates a single source tree used by all platforms. Instead of deciding at generation time whether to use the Interpreter struct the generated code depends on the SQ_USE_GLOBAL_STRUCT define which can be overridden in platform makefiles. All plugins live in src/plugins and platform makefiles along with plugins.int and plugins.ext files in the build subdirectories decide which plugins are built as external or internal. The VM Generation Workspace from Workspace.text workspace contains dots to generate the sources. We no longer use the VMMakerTool since there should be nothing platform-specific in the generated sources (if we add ports to other ISAs all their source can be included and selected as required by the platform makefiles).
Since the Cogit generates x86 machine code simulation is much more complex. There is a support plugin, platforms/Cross/plugins/BochsIA32Plugin that depends on a large simulation of the x86 family implemented in C++ (see processors/IA32/bochs) and on Alien. I use the simulator frequently (but note that I haven't had time to build a working version for Squeak 4.1). I have tested Cog simulation in this image, running on the image/VMMaker-Squeak4.1.image itself. The VM Simulation Workspace in the VMMaker image contains an example doit that starts the simulator. Be patient, even on a fast machine unhibernating the Squeak display background image takes nearly a minute. Native fonts do not (yet) simulate correctly, but the system runs. But note that I have only attempted to build and run the simulator on Mac OS X. I expect Bochs can be built on linux and win32 but I have not tried. By the way, I've not described how to run the Bochs simulator on the current Squeak VM. That's because the plugin depends on the heartbeat to break out of simulation occasionally via a new interpreterProxy entry point setInterruptCheckChain. As this isn't supported by the current Squeak VMs the plugin would require modification. So to simulate first build either of the Cog VMs and then run the simulation with it.
There are a number of unpublished changes to the base other than those in NecessaryImageChangesForCogToWork.1.cs. This is partly laziness on my part, partly avoiding publishing things in advance of Cog. These changes are better motivated once Cog is in use. There are changes to the "translated primitives" (see implementors of translatedPrimitives) which replace messages with method tags for generation directives. The Cog VMMaker uses Object>>perform:with:with:with:with: & Object>>perform:with:with:with:with:with: during simulation, and Collection>>#fold: & SquenceableCollection>>#copyUpThrough: during generation. Object>>inline: and Object var:declareC:, which are mispackaged in Kernel in Squeak 4.1 are obsolete (method tags being used instead) and have been removed. I have changed Integer>>hex and Integer>>hex8 back to their original semantics as of 3.8. Backward compatibility is important and one can easily add new selectors if one wants different functionality. VMMaker was here first ;)
Tarball:
The top-level directories in the tarball are
src
the tree for the Cog generated sources including all plugins
stacksrc/vm
the directory containing the Stack VM source (plugins can be taken from above)
platforms
the usual svn platform tree but including Cog specific changes such as the heartbeat
processors
the tree containing simulation support code, i.e. the bochs C++ x86 simulation library, along with a potential ARM, PowerPC & MIPS simulator, Skeye.
image
the Cog-prepared Squeak 4.1 VMMaker image
scripts
some svn scripts to revert unchanged plugins that haven't really changed
cygwinbuild
the win32 build directory
winbuild
the old win32 build directory for minnow gcc 2.95. Not entirely obsolete as the cygwin build as yet fails to generate a functional FFIPlugin
macbuild
the CoreVM.xcodeproj and support build projects for Mac OS X 10.5 or better
unixbuild
the build directory for linux
Building Cog:
Each build directory above contains a HowToBuild file that describes building in more detail. The build directories only contain Cogit makefiles. f you want to build a Stack VM you're on your own but this is very close to the existing Squeak VM build.
Status:
The Cogit VM has been our sole VM at Teleplace for nearly a year. We do occasionally find bugs and there are almost certainly areas of functionality that we have not touched (for example I know that co-routining does not yet work). If you find a bug please try and create a reproducible test case and let me know. I can't promise to take a look or fix it but I am motivated to do so and will try my best as time allows. Better still if you find and fix bugs be sure to let me know.
License (MIT):
All contributions from Teleplace in this release are
Copyright (c) 2010 Teleplace, Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
Eliot Miranda
June 2010
Eliot,
this is absolutely wonderful news. Thank you and everyone at Teleplace who made this possible.
Best wishes,
Michael
On Sun, Jun 20, 2010 at 10:11 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
it gives me great pleasure to announce that the Teleplace Cog VMs are now available. Huge thanks to all at Teleplace who have given me the opportunity to build Cog and release it as open source, been willing guinea pigs braving its bugs, and providing indispensable participation in getting Cog to its current state. Huge thanks are also due to the original Back To The Future team whose VMMaker Cog extends to write the VM, and to Peter Deutsch from whom I've taken many ideas.
This release contains two VMs. The Stack VM, is a cross-platform interpreter that uses context-to-stack mapping to achieve modest performance gains. The Cog VM is a just-in-time compiler that currently supports only x86 that builds upon the Stack VM to achieve substantial performance improvements. The release is in the form of a Monticello package containing the VMMaker source and a tarball containing the platform sources, the generated sources and a Squeak 4.1 image containing the VMMaker sources. Download both at
http://ftp.squeak.org/Cog/VMMaker-oscog.11.mcz
http://ftp.squeak.org/Cog/OpenSourceCog.tar.gz
Cog VMs:
The Cog VMs are Squeak/Croquet VMs that run closure Squeak/Croquet/Pharo/Cuis images. The VMs support existing plugin source but will require plugins to be recompiled as the VM_PROXY_MAJOR plugin api has been extended.
This release contains two distinct VMs, the StackInterpreter and the Cogit. The StackInterpreter is a fully-portable plug-in replacement for the current closure Squeak VMs and images. The Stack VM uses context-to-stack mapping and a somewhat improved garbage collector to achieve modest but useful performance gains in the 10% to 15% range. The StackInterpreter is intended to supersede the Squeak VM on platforms where the Cogit cannot be used. The Cogit extends the StackInterpreter with a just-in-time compiler that uses aggressive inline caching techniques to deliver substantial performance gains in the 3x to 15x range, depending on benchmark. The Cogit currently supports only x86 and the floating-point primitives and parts of the platform support code depend on SSE2. I hope members of the community will attempt to port it, e.g. to ARM, PowerPC and x86-64. The Cogit (excuse the pun) is so named because it is both an interpreter and a JIT, choosing not to generate machine code for large methods, interpreting them instead, the default policy being not to JIT methods with more than 60 literals.
The Cog VM requires a few minor image changes all in image/NecessaryImageChangesForCogToWork.1.cs. The JIT's machine-code SmallInteger primitives insist on a SmallInteger receiver so the primitives in LargePositiveInteger = ~= bitAnd: bitOr: butShift: and bitXor: cannot be used and these methods must be deleted. The Cogit inlines the address of the Character instance table, Smalltalk specialObjectsArray at: 25, into the machine-code at: primitive for faster ByteString>>at: and so the table cannot be rebuilt in SmalltalkImage>>recreateSpecialObjectsArray. The new version preserves the existing table. Both VMs maintain floats in platform order to ease implementation of machine code floating-point primitives, and hence internally are in little-endian order instead of big-endian in current Squeak images. While the VMs convert float order automatically on load they do require special accessing primitives Float>>basicAt: & Float>>basicAt:put: that undo the reversal and answer Float contents in big-endian order so that e.g. Float>>hash is unchanged. The methods assume these primitives can fail, allowing the code to be used on current Squeak VMs.
The image/VMMaker-Squeak4.1.image is a Squeak 4.1 image, runnable with the current Squeak VMs, that contains these changes, and can hence also be run with a Cog VM. But beware, once an image has been saved on Cog it cannot be run by an existing Squeak VM, because existing VMs cannot undo the Float order change.
Platform Subsystem:
Most of the platform subsystem is unchanged but there are some important changes that need description. The biggest change is the heartbeat and the clock in platforms/unix/vm/sqUnixHeartbeat.c and platforms/win32/vm/sqWin32Heartbeat.c. The Cog VMs avoid the slow and variable interruptCheckCounter, folding the event check into the stack overflow check on frame build. The heartbeat, typically 500Hz or 1KHz, changes the stackLimit to a value that will always fail. On the next frame building send the VM will enter stack overflow handling that, as a side effect, will also check for events. This is more efficient than the update of interruptCheckCounter and much more regular. If one is running code that executes long-running primitives (e.g. large integer arithmetic) the counter approach will result in too low an interrupt check frequency, and conversely if one is running normal code the interrupt check frequency can be very high.
The heartbeat also maintains a 64-bit microsecond clock, UTC microseconds from 1901, from which the backward-compatible millisecond and second clocks are derived. Primitives exist to answer UTC microseconds and local microseconds. Updating the clock in the heartbeat results in a 1 or 2 millisecond resolution but avoids the cost of accessing the OS time on every prim tie which we've found important for performance at Teleplace. The 64-bit microsecond clocks provide a unified time basis and eliminate wrapping (for the next 54,000 years at least). I hope community images will move to these clocks. It's worked well in VisualWorks.
Another significant change is in the external semaphore table support code. This is now lock-free at the cost of having to specify a maximum number of external semaphores at start-up (default 256). The support code for the lock-free data structures are processor-specific and is currently implemented only for x86 and gcc-compatible compilers; see platforms/Cross/vm/{sqAtomicOps.h,sqMemoryFence.h}.
There is also improved crash reporting code that prints a primitive log and a C backtrace in addition to the Smalltalk backtrace. See platforms/Mac OS/vm/sqMacMain.c, platforms/unix/vm/sqUnixMain.c, platforms/win32/vm/sqWin32Intel.c & platforms/win32/vm/sqWin32Backtrace.c.
Finally there is support for the QVMProfiler, a pc-sampling profiler for profiling at the VM level. See platforms/unix/vm/sqUnixVMProfile.c and platforms/win32/vm/sqWin32VMProfile.c. The profiler itself is in the VMMaker image described below in Qwaq-VMProfiling.
There are also changes to do with Teleplace-specific extensions to the HostWindowPlugin but these are not essential to Cog.
VMMaker and Slang:
The image/VMMaker-Squeak4.1.image Squeak 4.1 image contains the complete Cog VMMaker with necessary support code for simulation. This image was used to generate the sources in the src and stacksrc directories.
Cog's VMMaker is substantially revised and extended from the current VMMaker. It supports multiple classes, not just Interpreter and superclasses, because both context-to-stack mapping and the Cogit are too complex to write monolithically. Classes can specify ancilliaryClasses and ancilliaryStructClasses, such as CoInterpreterStackPage, CogMethod and CogAbstractInstruction. The Monticello package version is included in the header of all generated files and constitutes the version stamp for generated code. Code is generated in sorted order so that minor changes in the Smalltalk source produce correspondingly minor changes in the generated code. The gnuification step is built-in to VMMaker. No effort has been made to maintain 64-bit compatibility. Apologies, this was unaffordable.
The VMMaker generates a single source tree used by all platforms. Instead of deciding at generation time whether to use the Interpreter struct the generated code depends on the SQ_USE_GLOBAL_STRUCT define which can be overridden in platform makefiles. All plugins live in src/plugins and platform makefiles along with plugins.int and plugins.ext files in the build subdirectories decide which plugins are built as external or internal. The VM Generation Workspace from Workspace.text workspace contains dots to generate the sources. We no longer use the VMMakerTool since there should be nothing platform-specific in the generated sources (if we add ports to other ISAs all their source can be included and selected as required by the platform makefiles).
Since the Cogit generates x86 machine code simulation is much more complex. There is a support plugin, platforms/Cross/plugins/BochsIA32Plugin that depends on a large simulation of the x86 family implemented in C++ (see processors/IA32/bochs) and on Alien. I use the simulator frequently (but note that I haven't had time to build a working version for Squeak 4.1). I have tested Cog simulation in this image, running on the image/VMMaker-Squeak4.1.image itself. The VM Simulation Workspace in the VMMaker image contains an example doit that starts the simulator. Be patient, even on a fast machine unhibernating the Squeak display background image takes nearly a minute. Native fonts do not (yet) simulate correctly, but the system runs. But note that I have only attempted to build and run the simulator on Mac OS X. I expect Bochs can be built on linux and win32 but I have not tried. By the way, I've not described how to run the Bochs simulator on the current Squeak VM. That's because the plugin depends on the heartbeat to break out of simulation occasionally via a new interpreterProxy entry point setInterruptCheckChain. As this isn't supported by the current Squeak VMs the plugin would require modification. So to simulate first build either of the Cog VMs and then run the simulation with it.
There are a number of unpublished changes to the base other than those in NecessaryImageChangesForCogToWork.1.cs. This is partly laziness on my part, partly avoiding publishing things in advance of Cog. These changes are better motivated once Cog is in use. There are changes to the "translated primitives" (see implementors of translatedPrimitives) which replace messages with method tags for generation directives. The Cog VMMaker uses Object>>perform:with:with:with:with: & Object>>perform:with:with:with:with:with: during simulation, and Collection>>#fold: & SquenceableCollection>>#copyUpThrough: during generation. Object>>inline: and Object var:declareC:, which are mispackaged in Kernel in Squeak 4.1 are obsolete (method tags being used instead) and have been removed. I have changed Integer>>hex and Integer>>hex8 back to their original semantics as of 3.8. Backward compatibility is important and one can easily add new selectors if one wants different functionality. VMMaker was here first ;)
Tarball:
The top-level directories in the tarball are
src
the tree for the Cog generated sources including all plugins
stacksrc/vm
the directory containing the Stack VM source (plugins can be taken from above)
platforms
the usual svn platform tree but including Cog specific changes such as the heartbeat
processors
the tree containing simulation support code, i.e. the bochs C++ x86 simulation library, along with a potential ARM, PowerPC & MIPS simulator, Skeye.
image
the Cog-prepared Squeak 4.1 VMMaker image
scripts
some svn scripts to revert unchanged plugins that haven't really changed
cygwinbuild
the win32 build directory
winbuild
the old win32 build directory for minnow gcc 2.95. Not entirely obsolete as the cygwin build as yet fails to generate a functional FFIPlugin
macbuild
the CoreVM.xcodeproj and support build projects for Mac OS X 10.5 or better
unixbuild
the build directory for linux
Building Cog:
Each build directory above contains a HowToBuild file that describes building in more detail. The build directories only contain Cogit makefiles. f you want to build a Stack VM you're on your own but this is very close to the existing Squeak VM build.
Status:
The Cogit VM has been our sole VM at Teleplace for nearly a year. We do occasionally find bugs and there are almost certainly areas of functionality that we have not touched (for example I know that co-routining does not yet work). If you find a bug please try and create a reproducible test case and let me know. I can't promise to take a look or fix it but I am motivated to do so and will try my best as time allows. Better still if you find and fix bugs be sure to let me know.
License (MIT):
All contributions from Teleplace in this release are
Copyright (c) 2010 Teleplace, Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
Eliot Miranda
June 2010
This is really an excellent news. I open a lot of new futures! Thanks teleplace, andreas and all the people that helped.
Stef PS: you already answer my questions about platform were the jit cannot work so this is great.
On Jun 20, 2010, at 10:11 PM, Eliot Miranda wrote:
Hi All,
it gives me great pleasure to announce that the Teleplace Cog VMs are now available. Huge thanks to all at Teleplace who have given me the opportunity to build Cog and release it as open source, been willing guinea pigs braving its bugs, and providing indispensable participation in getting Cog to its current state. Huge thanks are also due to the original Back To The Future team whose VMMaker Cog extends to write the VM, and to Peter Deutsch from whom I've taken many ideas.
This release contains two VMs. The Stack VM, is a cross-platform interpreter that uses context-to-stack mapping to achieve modest performance gains. The Cog VM is a just-in-time compiler that currently supports only x86 that builds upon the Stack VM to achieve substantial performance improvements. The release is in the form of a Monticello package containing the VMMaker source and a tarball containing the platform sources, the generated sources and a Squeak 4.1 image containing the VMMaker sources. Download both at http://ftp.squeak.org/Cog/VMMaker-oscog.11.mcz http://ftp.squeak.org/Cog/OpenSourceCog.tar.gz
Cog VMs:
The Cog VMs are Squeak/Croquet VMs that run closure Squeak/Croquet/Pharo/Cuis images. The VMs support existing plugin source but will require plugins to be recompiled as the VM_PROXY_MAJOR plugin api has been extended.
This release contains two distinct VMs, the StackInterpreter and the Cogit. The StackInterpreter is a fully-portable plug-in replacement for the current closure Squeak VMs and images. The Stack VM uses context-to-stack mapping and a somewhat improved garbage collector to achieve modest but useful performance gains in the 10% to 15% range. The StackInterpreter is intended to supersede the Squeak VM on platforms where the Cogit cannot be used. The Cogit extends the StackInterpreter with a just-in-time compiler that uses aggressive inline caching techniques to deliver substantial performance gains in the 3x to 15x range, depending on benchmark. The Cogit currently supports only x86 and the floating-point primitives and parts of the platform support code depend on SSE2. I hope members of the community will attempt to port it, e.g. to ARM, PowerPC and x86-64. The Cogit (excuse the pun) is so named because it is both an interpreter and a JIT, choosing not to generate machine code for large methods, interpreting them instead, the default policy being not to JIT methods with more than 60 literals.
The Cog VM requires a few minor image changes all in image/NecessaryImageChangesForCogToWork.1.cs. The JIT's machine-code SmallInteger primitives insist on a SmallInteger receiver so the primitives in LargePositiveInteger = ~= bitAnd: bitOr: butShift: and bitXor: cannot be used and these methods must be deleted. The Cogit inlines the address of the Character instance table, Smalltalk specialObjectsArray at: 25, into the machine-code at: primitive for faster ByteString>>at: and so the table cannot be rebuilt in SmalltalkImage>>recreateSpecialObjectsArray. The new version preserves the existing table. Both VMs maintain floats in platform order to ease implementation of machine code floating-point primitives, and hence internally are in little-endian order instead of big-endian in current Squeak images. While the VMs convert float order automatically on load they do require special accessing primitives Float>>basicAt: & Float>>basicAt:put: that undo the reversal and answer Float contents in big-endian order so that e.g. Float>>hash is unchanged. The methods assume these primitives can fail, allowing the code to be used on current Squeak VMs.
The image/VMMaker-Squeak4.1.image is a Squeak 4.1 image, runnable with the current Squeak VMs, that contains these changes, and can hence also be run with a Cog VM. But beware, once an image has been saved on Cog it cannot be run by an existing Squeak VM, because existing VMs cannot undo the Float order change.
Platform Subsystem:
Most of the platform subsystem is unchanged but there are some important changes that need description. The biggest change is the heartbeat and the clock in platforms/unix/vm/sqUnixHeartbeat.c and platforms/win32/vm/sqWin32Heartbeat.c. The Cog VMs avoid the slow and variable interruptCheckCounter, folding the event check into the stack overflow check on frame build. The heartbeat, typically 500Hz or 1KHz, changes the stackLimit to a value that will always fail. On the next frame building send the VM will enter stack overflow handling that, as a side effect, will also check for events. This is more efficient than the update of interruptCheckCounter and much more regular. If one is running code that executes long-running primitives (e.g. large integer arithmetic) the counter approach will result in too low an interrupt check frequency, and conversely if one is running normal code the interrupt check frequency can be very high.
The heartbeat also maintains a 64-bit microsecond clock, UTC microseconds from 1901, from which the backward-compatible millisecond and second clocks are derived. Primitives exist to answer UTC microseconds and local microseconds. Updating the clock in the heartbeat results in a 1 or 2 millisecond resolution but avoids the cost of accessing the OS time on every prim tie which we've found important for performance at Teleplace. The 64-bit microsecond clocks provide a unified time basis and eliminate wrapping (for the next 54,000 years at least). I hope community images will move to these clocks. It's worked well in VisualWorks.
Another significant change is in the external semaphore table support code. This is now lock-free at the cost of having to specify a maximum number of external semaphores at start-up (default 256). The support code for the lock-free data structures are processor-specific and is currently implemented only for x86 and gcc-compatible compilers; see platforms/Cross/vm/{sqAtomicOps.h,sqMemoryFence.h}.
There is also improved crash reporting code that prints a primitive log and a C backtrace in addition to the Smalltalk backtrace. See platforms/Mac OS/vm/sqMacMain.c, platforms/unix/vm/sqUnixMain.c, platforms/win32/vm/sqWin32Intel.c & platforms/win32/vm/sqWin32Backtrace.c.
Finally there is support for the QVMProfiler, a pc-sampling profiler for profiling at the VM level. See platforms/unix/vm/sqUnixVMProfile.c and platforms/win32/vm/sqWin32VMProfile.c. The profiler itself is in the VMMaker image described below in Qwaq-VMProfiling.
There are also changes to do with Teleplace-specific extensions to the HostWindowPlugin but these are not essential to Cog.
VMMaker and Slang:
The image/VMMaker-Squeak4.1.image Squeak 4.1 image contains the complete Cog VMMaker with necessary support code for simulation. This image was used to generate the sources in the src and stacksrc directories.
Cog's VMMaker is substantially revised and extended from the current VMMaker. It supports multiple classes, not just Interpreter and superclasses, because both context-to-stack mapping and the Cogit are too complex to write monolithically. Classes can specify ancilliaryClasses and ancilliaryStructClasses, such as CoInterpreterStackPage, CogMethod and CogAbstractInstruction. The Monticello package version is included in the header of all generated files and constitutes the version stamp for generated code. Code is generated in sorted order so that minor changes in the Smalltalk source produce correspondingly minor changes in the generated code. The gnuification step is built-in to VMMaker. No effort has been made to maintain 64-bit compatibility. Apologies, this was unaffordable.
The VMMaker generates a single source tree used by all platforms. Instead of deciding at generation time whether to use the Interpreter struct the generated code depends on the SQ_USE_GLOBAL_STRUCT define which can be overridden in platform makefiles. All plugins live in src/plugins and platform makefiles along with plugins.int and plugins.ext files in the build subdirectories decide which plugins are built as external or internal. The VM Generation Workspace from Workspace.text workspace contains dots to generate the sources. We no longer use the VMMakerTool since there should be nothing platform-specific in the generated sources (if we add ports to other ISAs all their source can be included and selected as required by the platform makefiles).
Since the Cogit generates x86 machine code simulation is much more complex. There is a support plugin, platforms/Cross/plugins/BochsIA32Plugin that depends on a large simulation of the x86 family implemented in C++ (see processors/IA32/bochs) and on Alien. I use the simulator frequently (but note that I haven't had time to build a working version for Squeak 4.1). I have tested Cog simulation in this image, running on the image/VMMaker-Squeak4.1.image itself. The VM Simulation Workspace in the VMMaker image contains an example doit that starts the simulator. Be patient, even on a fast machine unhibernating the Squeak display background image takes nearly a minute. Native fonts do not (yet) simulate correctly, but the system runs. But note that I have only attempted to build and run the simulator on Mac OS X. I expect Bochs can be built on linux and win32 but I have not tried. By the way, I've not described how to run the Bochs simulator on the current Squeak VM. That's because the plugin depends on the heartbeat to break out of simulation occasionally via a new interpreterProxy entry point setInterruptCheckChain. As this isn't supported by the current Squeak VMs the plugin would require modification. So to simulate first build either of the Cog VMs and then run the simulation with it.
There are a number of unpublished changes to the base other than those in NecessaryImageChangesForCogToWork.1.cs. This is partly laziness on my part, partly avoiding publishing things in advance of Cog. These changes are better motivated once Cog is in use. There are changes to the "translated primitives" (see implementors of translatedPrimitives) which replace messages with method tags for generation directives. The Cog VMMaker uses Object>>perform:with:with:with:with: & Object>>perform:with:with:with:with:with: during simulation, and Collection>>#fold: & SquenceableCollection>>#copyUpThrough: during generation. Object>>inline: and Object var:declareC:, which are mispackaged in Kernel in Squeak 4.1 are obsolete (method tags being used instead) and have been removed. I have changed Integer>>hex and Integer>>hex8 back to their original semantics as of 3.8. Backward compatibility is important and one can easily add new selectors if one wants different functionality. VMMaker was here first ;)
Tarball:
The top-level directories in the tarball are
src the tree for the Cog generated sources including all plugins stacksrc/vm the directory containing the Stack VM source (plugins can be taken from above) platforms the usual svn platform tree but including Cog specific changes such as the heartbeat processors the tree containing simulation support code, i.e. the bochs C++ x86 simulation library, along with a potential ARM, PowerPC & MIPS simulator, Skeye.
image the Cog-prepared Squeak 4.1 VMMaker image scripts some svn scripts to revert unchanged plugins that haven't really changed
cygwinbuild the win32 build directory winbuild the old win32 build directory for minnow gcc 2.95. Not entirely obsolete as the cygwin build as yet fails to generate a functional FFIPlugin macbuild the CoreVM.xcodeproj and support build projects for Mac OS X 10.5 or better unixbuild the build directory for linux
Building Cog:
Each build directory above contains a HowToBuild file that describes building in more detail. The build directories only contain Cogit makefiles. f you want to build a Stack VM you're on your own but this is very close to the existing Squeak VM build.
Status: The Cogit VM has been our sole VM at Teleplace for nearly a year. We do occasionally find bugs and there are almost certainly areas of functionality that we have not touched (for example I know that co-routining does not yet work). If you find a bug please try and create a reproducible test case and let me know. I can't promise to take a look or fix it but I am motivated to do so and will try my best as time allows. Better still if you find and fix bugs be sure to let me know.
License (MIT): All contributions from Teleplace in this release are Copyright (c) 2010 Teleplace, Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Eliot Miranda June 2010
Thank you Eliot.
This is wonderful, it feels like I just got a new laptop :-)
I noticed some problems in the continuation tests of Seaside (WAContinuationTest, WAFlowPlatformTest and WAPartialContinuationTest):
"Computation has been terminated" in MethodContext>>cannotReturn:
Is this a known problem? Or is this maybe specific to Pharo on Cog?
Cheers, Lukas
On 20 June 2010 22:53, stephane ducasse stephane.ducasse@gmail.com wrote:
This is really an excellent news. I open a lot of new futures! Thanks teleplace, andreas and all the people that helped.
Stef PS: you already answer my questions about platform were the jit cannot work so this is great.
On Jun 20, 2010, at 10:11 PM, Eliot Miranda wrote:
Hi All,
it gives me great pleasure to announce that the Teleplace Cog VMs are now available. Huge thanks to all at Teleplace who have given me the opportunity to build Cog and release it as open source, been willing guinea pigs braving its bugs, and providing indispensable participation in getting Cog to its current state. Huge thanks are also due to the original Back To The Future team whose VMMaker Cog extends to write the VM, and to Peter Deutsch from whom I've taken many ideas.
This release contains two VMs. The Stack VM, is a cross-platform interpreter that uses context-to-stack mapping to achieve modest performance gains. The Cog VM is a just-in-time compiler that currently supports only x86 that builds upon the Stack VM to achieve substantial performance improvements. The release is in the form of a Monticello package containing the VMMaker source and a tarball containing the platform sources, the generated sources and a Squeak 4.1 image containing the VMMaker sources. Download both at http://ftp.squeak.org/Cog/VMMaker-oscog.11.mcz http://ftp.squeak.org/Cog/OpenSourceCog.tar.gz
Cog VMs:
The Cog VMs are Squeak/Croquet VMs that run closure Squeak/Croquet/Pharo/Cuis images. The VMs support existing plugin source but will require plugins to be recompiled as the VM_PROXY_MAJOR plugin api has been extended.
This release contains two distinct VMs, the StackInterpreter and the Cogit. The StackInterpreter is a fully-portable plug-in replacement for the current closure Squeak VMs and images. The Stack VM uses context-to-stack mapping and a somewhat improved garbage collector to achieve modest but useful performance gains in the 10% to 15% range. The StackInterpreter is intended to supersede the Squeak VM on platforms where the Cogit cannot be used. The Cogit extends the StackInterpreter with a just-in-time compiler that uses aggressive inline caching techniques to deliver substantial performance gains in the 3x to 15x range, depending on benchmark. The Cogit currently supports only x86 and the floating-point primitives and parts of the platform support code depend on SSE2. I hope members of the community will attempt to port it, e.g. to ARM, PowerPC and x86-64. The Cogit (excuse the pun) is so named because it is both an interpreter and a JIT, choosing not to generate machine code for large methods, interpreting them instead, the default policy being not to JIT methods with more than 60 literals.
The Cog VM requires a few minor image changes all in image/NecessaryImageChangesForCogToWork.1.cs. The JIT's machine-code SmallInteger primitives insist on a SmallInteger receiver so the primitives in LargePositiveInteger = ~= bitAnd: bitOr: butShift: and bitXor: cannot be used and these methods must be deleted. The Cogit inlines the address of the Character instance table, Smalltalk specialObjectsArray at: 25, into the machine-code at: primitive for faster ByteString>>at: and so the table cannot be rebuilt in SmalltalkImage>>recreateSpecialObjectsArray. The new version preserves the existing table. Both VMs maintain floats in platform order to ease implementation of machine code floating-point primitives, and hence internally are in little-endian order instead of big-endian in current Squeak images. While the VMs convert float order automatically on load they do require special accessing primitives Float>>basicAt: & Float>>basicAt:put: that undo the reversal and answer Float contents in big-endian order so that e.g. Float>>hash is unchanged. The methods assume these primitives can fail, allowing the code to be used on current Squeak VMs.
The image/VMMaker-Squeak4.1.image is a Squeak 4.1 image, runnable with the current Squeak VMs, that contains these changes, and can hence also be run with a Cog VM. But beware, once an image has been saved on Cog it cannot be run by an existing Squeak VM, because existing VMs cannot undo the Float order change.
Platform Subsystem:
Most of the platform subsystem is unchanged but there are some important changes that need description. The biggest change is the heartbeat and the clock in platforms/unix/vm/sqUnixHeartbeat.c and platforms/win32/vm/sqWin32Heartbeat.c. The Cog VMs avoid the slow and variable interruptCheckCounter, folding the event check into the stack overflow check on frame build. The heartbeat, typically 500Hz or 1KHz, changes the stackLimit to a value that will always fail. On the next frame building send the VM will enter stack overflow handling that, as a side effect, will also check for events. This is more efficient than the update of interruptCheckCounter and much more regular. If one is running code that executes long-running primitives (e.g. large integer arithmetic) the counter approach will result in too low an interrupt check frequency, and conversely if one is running normal code the interrupt check frequency can be very high.
The heartbeat also maintains a 64-bit microsecond clock, UTC microseconds from 1901, from which the backward-compatible millisecond and second clocks are derived. Primitives exist to answer UTC microseconds and local microseconds. Updating the clock in the heartbeat results in a 1 or 2 millisecond resolution but avoids the cost of accessing the OS time on every prim tie which we've found important for performance at Teleplace. The 64-bit microsecond clocks provide a unified time basis and eliminate wrapping (for the next 54,000 years at least). I hope community images will move to these clocks. It's worked well in VisualWorks.
Another significant change is in the external semaphore table support code. This is now lock-free at the cost of having to specify a maximum number of external semaphores at start-up (default 256). The support code for the lock-free data structures are processor-specific and is currently implemented only for x86 and gcc-compatible compilers; see platforms/Cross/vm/{sqAtomicOps.h,sqMemoryFence.h}.
There is also improved crash reporting code that prints a primitive log and a C backtrace in addition to the Smalltalk backtrace. See platforms/Mac OS/vm/sqMacMain.c, platforms/unix/vm/sqUnixMain.c, platforms/win32/vm/sqWin32Intel.c & platforms/win32/vm/sqWin32Backtrace.c.
Finally there is support for the QVMProfiler, a pc-sampling profiler for profiling at the VM level. See platforms/unix/vm/sqUnixVMProfile.c and platforms/win32/vm/sqWin32VMProfile.c. The profiler itself is in the VMMaker image described below in Qwaq-VMProfiling.
There are also changes to do with Teleplace-specific extensions to the HostWindowPlugin but these are not essential to Cog.
VMMaker and Slang:
The image/VMMaker-Squeak4.1.image Squeak 4.1 image contains the complete Cog VMMaker with necessary support code for simulation. This image was used to generate the sources in the src and stacksrc directories.
Cog's VMMaker is substantially revised and extended from the current VMMaker. It supports multiple classes, not just Interpreter and superclasses, because both context-to-stack mapping and the Cogit are too complex to write monolithically. Classes can specify ancilliaryClasses and ancilliaryStructClasses, such as CoInterpreterStackPage, CogMethod and CogAbstractInstruction. The Monticello package version is included in the header of all generated files and constitutes the version stamp for generated code. Code is generated in sorted order so that minor changes in the Smalltalk source produce correspondingly minor changes in the generated code. The gnuification step is built-in to VMMaker. No effort has been made to maintain 64-bit compatibility. Apologies, this was unaffordable.
The VMMaker generates a single source tree used by all platforms. Instead of deciding at generation time whether to use the Interpreter struct the generated code depends on the SQ_USE_GLOBAL_STRUCT define which can be overridden in platform makefiles. All plugins live in src/plugins and platform makefiles along with plugins.int and plugins.ext files in the build subdirectories decide which plugins are built as external or internal. The VM Generation Workspace from Workspace.text workspace contains dots to generate the sources. We no longer use the VMMakerTool since there should be nothing platform-specific in the generated sources (if we add ports to other ISAs all their source can be included and selected as required by the platform makefiles).
Since the Cogit generates x86 machine code simulation is much more complex. There is a support plugin, platforms/Cross/plugins/BochsIA32Plugin that depends on a large simulation of the x86 family implemented in C++ (see processors/IA32/bochs) and on Alien. I use the simulator frequently (but note that I haven't had time to build a working version for Squeak 4.1). I have tested Cog simulation in this image, running on the image/VMMaker-Squeak4.1.image itself. The VM Simulation Workspace in the VMMaker image contains an example doit that starts the simulator. Be patient, even on a fast machine unhibernating the Squeak display background image takes nearly a minute. Native fonts do not (yet) simulate correctly, but the system runs. But note that I have only attempted to build and run the simulator on Mac OS X. I expect Bochs can be built on linux and win32 but I have not tried. By the way, I've not described how to run the Bochs simulator on the current Squeak VM. That's because the plugin depends on the heartbeat to break out of simulation occasionally via a new interpreterProxy entry point setInterruptCheckChain. As this isn't supported by the current Squeak VMs the plugin would require modification. So to simulate first build either of the Cog VMs and then run the simulation with it.
There are a number of unpublished changes to the base other than those in NecessaryImageChangesForCogToWork.1.cs. This is partly laziness on my part, partly avoiding publishing things in advance of Cog. These changes are better motivated once Cog is in use. There are changes to the "translated primitives" (see implementors of translatedPrimitives) which replace messages with method tags for generation directives. The Cog VMMaker uses Object>>perform:with:with:with:with: & Object>>perform:with:with:with:with:with: during simulation, and Collection>>#fold: & SquenceableCollection>>#copyUpThrough: during generation. Object>>inline: and Object var:declareC:, which are mispackaged in Kernel in Squeak 4.1 are obsolete (method tags being used instead) and have been removed. I have changed Integer>>hex and Integer>>hex8 back to their original semantics as of 3.8. Backward compatibility is important and one can easily add new selectors if one wants different functionality. VMMaker was here first ;)
Tarball:
The top-level directories in the tarball are
src the tree for the Cog generated sources including all plugins stacksrc/vm the directory containing the Stack VM source (plugins can be taken from above) platforms the usual svn platform tree but including Cog specific changes such as the heartbeat processors the tree containing simulation support code, i.e. the bochs C++ x86 simulation library, along with a potential ARM, PowerPC & MIPS simulator, Skeye.
image the Cog-prepared Squeak 4.1 VMMaker image scripts some svn scripts to revert unchanged plugins that haven't really changed
cygwinbuild the win32 build directory winbuild the old win32 build directory for minnow gcc 2.95. Not entirely obsolete as the cygwin build as yet fails to generate a functional FFIPlugin macbuild the CoreVM.xcodeproj and support build projects for Mac OS X 10.5 or better unixbuild the build directory for linux
Building Cog:
Each build directory above contains a HowToBuild file that describes building in more detail. The build directories only contain Cogit makefiles. f you want to build a Stack VM you're on your own but this is very close to the existing Squeak VM build.
Status: The Cogit VM has been our sole VM at Teleplace for nearly a year. We do occasionally find bugs and there are almost certainly areas of functionality that we have not touched (for example I know that co-routining does not yet work). If you find a bug please try and create a reproducible test case and let me know. I can't promise to take a look or fix it but I am motivated to do so and will try my best as time allows. Better still if you find and fix bugs be sure to let me know.
License (MIT): All contributions from Teleplace in this release are Copyright (c) 2010 Teleplace, Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Eliot Miranda June 2010
On Sun, Jun 20, 2010 at 2:23 PM, Lukas Renggli renggli@gmail.com wrote:
Thank you Eliot.
This is wonderful, it feels like I just got a new laptop :-)
:)
I noticed some problems in the continuation tests of Seaside (WAContinuationTest, WAFlowPlatformTest and WAPartialContinuationTest):
"Computation has been terminated" in MethodContext>>cannotReturn:
Is this a known problem? Or is this maybe specific to Pharo on Cog?
This is a known area of problems. From my announcement:
Status: The Cogit VM has been our sole VM at Teleplace for nearly a year. We do occasionally find bugs and there are almost certainly areas of functionality that we have not touched (*for example I know that co-routining does not yet work*). If you find a bug please try and create a reproducible test case and let me know. I can't promise to take a look or fix it but I am motivated to do so and will try my best as time allows. Better still if you find and fix bugs be sure to let me know.
The use of context-to-stack mapping is fundamental to the performance improvements in Cog and it *should* be transparent, but so far I've only fixed what issues we've encountered in our usage at Teleplace. I expect the next few weeks to involve some bug fixing as it is used in a much broader context (no pun intended). Y'all can help by giving me reproducible test cases. This can be in the form of a precise specification of an image configuration and a doit, but even easier is to save an image that exhibits the crash on start-up. e.g. Smalltalk saveAs: 'crash.image' thenQuit: true. MyClass crashTheVM
I also need to write the sequence of blog posts on the JIT I've been meaning to write for over a year now, as others will want to understand and, I hope, port Cog to other processors.
There's also the need to improve performance. Right now the code generator is a very naive JIT where every there is no inter-bytecode optimization and hence every push or pop in the bytecode is reflected in a real push or pop in the native code. This makes loops such as 1 to: n do: [:i|... ] very slow because the send: #<= (1 arg); jumpFalseTo: L2 in the underlying code actually runs a non-inlined SmallInteger <= primitive which pushes the actual true object, which the jump bytecode must compare against the actual true false object. In the VisualWorks code generator the JIT spits out two paths here, one that tests or SmallIntegers and then does the comparison and jump directly branching on the condition codes. Consequently loops in VsualWorks are much faster. Also, the object representation is convoluted, compact classes being OK for reducing space overhead but bad at creating overhead and complexity, so much so that Cog as yet lacks machine code primitives for instance creation and at:put:.
So I hope that soon we'll upgrade the code generator and the object representation and will see another significant jump in compute performance to bring us up to VisualWorks levels. I hope that we'll also start working on inlining and get the fastest Smalltalk VM ever. We have a really exciting opportunity here with Exupery and Igor's Native Boost to do inlining in a Klein-like way, i.e. having SMalltalk code do inlining and code optimization. The only concern here is portability; keeping an intermediate bytecode might be wise. But we'll see. I'm also going to be working on the FFI, in part with my GSoC student, but also in Teleplace where I have threaded/non-blocking/overlapped calls woking in prototype form, but as yet lack proper calbacks.
So that speculation aside please do prepare reproducible cases of crashes or differences in behaviour between the current VM and Cog (I've just remembered that another difference is that Cog will produce Float infinity for 1.0/0.0 instead of failing). Crashes need to be fixed. Some semantic issues may need to change (for example I think the floating-point behaviour is better, does this need a flag to control as in VisualWorks's case, etc). But Cog being available is only the beginning, and now we can all be involved.
cheers Eliot
Howdy!
First: Super fun and cool! I am of course *very* happy to see Cog released.
Now, over to some "testing"...
SIDENOTE: First btw I ran pystone.py with regular Python 2.6.5 on my Lucid Lynx, then in the latest "regular" VM from Squeakvm.org. Result:
Python: 36k pystones Squeak: 45k pystones
So... the good ole VM is still a tad faster than CPython in that bench. :)
Now, I wanted to try it out with Cogit. Trouble begins! :)
I am using the tar ball on a Lucid laptop.
1. vm-sound-NAS does not compile! Lots of compile errors, probably due to a new upstream NAS. So try to get rid of that plugin... is harder than I thought! I finally ended up hacking the configure script to "fail" on the compile check by trying to compile rubbish. ;)
2. For some odd reason this will still create duplicate lines about NAS in disabledPlugins.c, just manually remove one of them, fine. Tada! Got a VM binary.
3. Fire it up on a *vanilla* Squeak4.1.1.image. BOOM, segfault. This is a "full debug VM" per instructions in HowToBuild. Anyway, see all info below, and tell me if there is more you want. :)
Btw, is there some nice existing script to run to "collect data about the box" that does uname etc?
regards, Göran ------------------ gokr@yoda:~/squeak$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU U2500 @ 1.20GHz stepping : 8 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm bogomips : 2393.82 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management:
gokr@yoda:~/squeak$ gcc --version gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gokr@yoda:~/squeak$ uname -a Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC 2010 i686 GNU/Linux
gokr@yoda:~/squeak$ squeak -version 3.9-7 #1 Mon Jun 21 13:20:28 CEST 2010 gcc 4.4.3 Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.11] Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC 2010 i686 GNU/Linux plugin path: /usr/local/lib/squeak/3.9-7/ [default: /usr/local/lib/squeak/3.9-7/]
gokr@yoda:~/squeak$ squeak Squeak4.1.1.image
((rcvr & 1)) || (addressCouldBeObj(rcvr)) 11334
Segmentation fault
Smalltalk stack dump: 0xbfc87e08 M GradientFillStyle>scaledAlphaMix:of:with: 2018669100: a(n) GradientFillStyle 0xbfc87e5c M [] in GradientFillStyle>computePixelRampOfSize: 2018669100: a(n) GradientFillStyle 0xbfc87e7c M SortedCollection(OrderedCollection)>do: 2018669424: a(n) SortedCollection 0xbfc87eb4 I GradientFillStyle>computePixelRampOfSize: 2018669100: a(n) GradientFillStyle 0xbfc87ed8 I [] in GradientFillStyle class>initPixelRampCache 2007164144: a(n) GradientFillStyle class 0xbfc87f10 I LRUCache>at: 2012963616: a(n) LRUCache 0xbfc87f2c M GradientFillStyle>pixelRamp 2018529312: a(n) GradientFillStyle 0xbfc87f4c M BalloonEngine>registerFill: 2018659444: a(n) BalloonEngine 0xbfc87f74 M BalloonEngine>registerFills: 2018659444: a(n) BalloonEngine 0xbfc87f90 M BalloonEngine>registerFill:and: 2018659444: a(n) BalloonEngine 0xbfc87fb4 M BalloonEngine>drawRectangle:fill:borderWidth:borderColor:transform: 2018659444: a(n) BalloonEngine 0xbfc87fe8 M BalloonCanvas>drawRectangle:color:borderWidth:borderColor: 2018659252: a(n) BalloonCanvas 0xbfc88010 M BalloonCanvas>fillRectangle:fillStyle: 2018659252: a(n) BalloonCanvas 0xbfc88030 M FormCanvas>balloonFillRectangle:fillStyle: 2018611404: a(n) FormCanvas 0xbfc88054 M FormCanvas>fillRectangle:fillStyle: 2018611404: a(n) FormCanvas 0xbfc88074 M FormCanvas(Canvas)>fillRectangle:fillStyle:borderStyle: 2018611404: a(n) FormCanvas 0xbfc88098 M SystemWindow(Morph)>drawOn: 2014426088: a(n) SystemWindow 0xbfc880b4 M FormCanvas(Canvas)>draw: 2018611404: a(n) FormCanvas 0xbfc880d0 M FormCanvas(Canvas)>drawMorph: 2018611404: a(n) FormCanvas 0xbfc880f0 M [] in SystemWindow(Morph)>fullDrawOn: 2014426088: a(n) SystemWindow 0xbfc8810c M CornerRounder class>roundCornersOf:on:in:displayBlock:borderWidth:corners: 2007442196: a(n) CornerRounder class 0xbfc8813c M FormCanvas>roundCornersOf:in:during: 2018611404: a(n) FormCanvas 0xbfc88160 M FormCanvas(Canvas)>roundCornersOf:during: 2018611404: a(n) FormCanvas 0xbfc88180 M SystemWindow(Morph)>fullDrawOn: 2014426088: a(n) SystemWindow 0xbfc8819c M FormCanvas(Canvas)>fullDraw: 2018611404: a(n) FormCanvas 0xbfc881b8 M FormCanvas(Canvas)>fullDrawMorph: 2018611404: a(n) FormCanvas 0xbfc88208 M [] in WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: a(n) WorldState 0xbfc88240 I Rectangle>allAreasOutsideList:startingAt:do: 2017358104: a(n) Rectangle 0xbfc8826c I Rectangle>allAreasOutsideList:do: 2017358104: a(n) Rectangle 0xbfc882a8 M [] in WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: a(n) WorldState 0xbfc882cc M Array(SequenceableCollection)>do: 2018529764: a(n) Array 0xbfc882fc M WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: a(n) WorldState 0xbfc88334 M [] in WorldState>displayWorld:submorphs: 2001318316: a(n) WorldState 0xbfc8834c M FormCanvas>roundCornersOf:in:during: 2017358448: a(n) FormCanvas 0xbfc88370 M FormCanvas(Canvas)>roundCornersOf:during: 2017358448: a(n) FormCanvas 0xbfc88398 M WorldState>displayWorld:submorphs: 2001318316: a(n) WorldState 0xbfc883c0 I PasteUpMorph>privateOuterDisplayWorld 2001318568: a(n) PasteUpMorph 0xbfc883e0 I PasteUpMorph>displayWorld 2001318568: a(n) PasteUpMorph 0xbfc88404 I [] in WorldState>displayWorldSafely: 2001318316: a(n) WorldState 0xbfc88420 M BlockClosure>on:do: 2018529472: a(n) BlockClosure 0xbfc88440 M BlockClosure>ifError: 2018529472: a(n) BlockClosure 0xbfc88464 I WorldState>displayWorldSafely: 2001318316: a(n) WorldState 0xbfc88480 M PasteUpMorph>displayWorldSafely 2001318568: a(n) PasteUpMorph 0xbfc88498 M PasteUpMorph>install 2001318568: a(n) PasteUpMorph 0xbfc884c0 I AutoStart class>checkForPluginUpdate 2008299932: a(n) AutoStart class 0xbfc884e0 M AutoStart class>startUp: 2008299932: a(n) AutoStart class 0xbfc8850c M [] in SmalltalkImage>send:toClassesNamedIn:with: 2009624740: a(n) SmalltalkImage 0xbfc88534 I OrderedCollection>do: 2009661056: a(n) OrderedCollection 0xbfc8855c I SmalltalkImage>send:toClassesNamedIn:with: 2009624740: a(n) SmalltalkImage 0xbfc88588 I SmalltalkImage>processStartUpList: 2009624740: a(n) SmalltalkImage 0xbfc885b4 I SmalltalkImage>snapshot:andQuit:embedded: 2009624740: a(n) SmalltalkImage 2014606248 s SmalltalkImage>snapshot:andQuit: 2014606132 s TheWorldMainDockingBar>saveAndQuitSqueak 2014606040 s [] in MenuItemMorph>invokeWithEvent: 2014605924 s BlockClosure>ensure: 2014605832 s CursorWithMask(Cursor)>showWhile: 2014605632 s MenuItemMorph>invokeWithEvent: 2014605540 s MenuItemMorph>mouseUp: 2014605448 s MenuItemMorph>handleMouseUp: 2014605316 s MouseButtonEvent>sentTo: 2014605224 s MenuItemMorph(Morph)>handleEvent: 2014605132 s MorphicEventDispatcher>dispatchDefault:with: 2014605040 s MorphicEventDispatcher>dispatchEvent:with: 2014604948 s MenuItemMorph(Morph)>processEvent:using: 2014604856 s MorphicEventDispatcher>dispatchDefault:with: 2014604748 s MorphicEventDispatcher>dispatchEvent:with: 2014604616 s DockingBarMenuMorph(Morph)>processEvent:using: 2014604524 s DockingBarMenuMorph(Morph)>processEvent: 2014604432 s DockingBarMenuMorph(MenuMorph)>handleFocusEvent: 2014604340 s [] in HandMorph>sendFocusEvent:to:clear: 2014604248 s [] in PasteUpMorph>becomeActiveDuring: 2014604068 s BlockClosure>on:do: 2014603976 s PasteUpMorph>becomeActiveDuring: 2014603856 s HandMorph>sendFocusEvent:to:clear: 2014603764 s HandMorph>sendEvent:focus:clear: 2014603672 s HandMorph>sendMouseEvent: 2014603528 s HandMorph>handleEvent: 2014603180 s HandMorph>processEvents 2014603064 s [] in WorldState>doOneCycleNowFor: 2014602972 s Array(SequenceableCollection)>do: 2014602872 s WorldState>handsDo: 2014602780 s WorldState>doOneCycleNowFor: 2014602688 s WorldState>doOneCycleFor: 2014602596 s PasteUpMorph>doOneCycle 2010011832 s [] in Project class>spawnNewProcess 2010011700 s [] in BlockClosure>newProcess
Most recent primitives basicNew copyBits @ @ @ basicNew @ @ basicNew @ @ @ basicNew copyBits @ @ @ basicNew @ copyBits @ @ @ basicNew basicNew: at:put: @ copyBits @ @ @ basicNew @ @ @ basicNew shallowCopy new: @ @ new: at:put: at:put: at:put: at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ @ basicNew@ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ perform:with: @ @ perform:with: @ basicNew basicNew @ @ @ basicNew basicNew basicNew basicNew new: basicNew: basicNew primitiveSetBitBltPlugin: @ @ basicNew @ @ basicNew @ @ basicNew @ primitiveSetBitBltPlugin: @ @ basicNew @ @ basicNew @ @ basicNew @ @ wait at:put: signal primInitializeBuffer: primSetAALevel: primSetOffset: primSetClipRect: primSetEdgeTransform: primSetColorTransform: primSetEdgeTransform: primSetColorTransform: primGetDepth primSetDepth: new: at:put: at:put: basicNew: species stringHash:initialHash: fractionPart truncated fractionPart fractionPart truncated basicNew basicNew new: value: at:put: value: at:put: at:put: value:value: value:value: basicNew: basicNew: at:put: at:put: at:put: at:put: fractionPart truncated basicNew: at:put: at:put: at:put: at:put: fractionPart truncated basicNew: at:put: at:put: at:put: at:put: truncated truncated truncated truncated at:put: perform:with: truncated Aborted gokr@yoda:~/squeak$
This is what happens when you are still using the LargeInteger prims. Execute
#(= bitAnd: bitOr: bitShift: bitXor: ~=) do:[:sel| LargePositiveInteger removeSelector: sel. ]. save the image, then you should be able to open without segfaulting.
Cheers, Henry
On Jun 21, 2010, at 1:39 51PM, Göran Krampe wrote:
Howdy!
First: Super fun and cool! I am of course *very* happy to see Cog released.
Now, over to some "testing"...
SIDENOTE: First btw I ran pystone.py with regular Python 2.6.5 on my Lucid Lynx, then in the latest "regular" VM from Squeakvm.org. Result:
Python: 36k pystones Squeak: 45k pystones
So... the good ole VM is still a tad faster than CPython in that bench. :)
Now, I wanted to try it out with Cogit. Trouble begins! :)
I am using the tar ball on a Lucid laptop.
vm-sound-NAS does not compile! Lots of compile errors, probably due to a new upstream NAS. So try to get rid of that plugin... is harder than I thought! I finally ended up hacking the configure script to "fail" on the compile check by trying to compile rubbish. ;)
For some odd reason this will still create duplicate lines about NAS in disabledPlugins.c, just manually remove one of them, fine. Tada! Got a VM binary.
Fire it up on a *vanilla* Squeak4.1.1.image. BOOM, segfault. This is a "full debug VM" per instructions in HowToBuild. Anyway, see all info below, and tell me if there is more you want. :)
Btw, is there some nice existing script to run to "collect data about the box" that does uname etc?
regards, Göran
gokr@yoda:~/squeak$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU U2500 @ 1.20GHz stepping : 8 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm bogomips : 2393.82 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management:
gokr@yoda:~/squeak$ gcc --version gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gokr@yoda:~/squeak$ uname -a Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC 2010 i686 GNU/Linux
gokr@yoda:~/squeak$ squeak -version 3.9-7 #1 Mon Jun 21 13:20:28 CEST 2010 gcc 4.4.3 Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.11] Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC 2010 i686 GNU/Linux plugin path: /usr/local/lib/squeak/3.9-7/ [default: /usr/local/lib/squeak/3.9-7/]
gokr@yoda:~/squeak$ squeak Squeak4.1.1.image
((rcvr & 1)) || (addressCouldBeObj(rcvr)) 11334
Segmentation fault
Smalltalk stack dump: 0xbfc87e08 M GradientFillStyle>scaledAlphaMix:of:with: 2018669100: a(n) GradientFillStyle 0xbfc87e5c M [] in GradientFillStyle>computePixelRampOfSize: 2018669100: a(n) GradientFillStyle 0xbfc87e7c M SortedCollection(OrderedCollection)>do: 2018669424: a(n) SortedCollection 0xbfc87eb4 I GradientFillStyle>computePixelRampOfSize: 2018669100: a(n) GradientFillStyle 0xbfc87ed8 I [] in GradientFillStyle class>initPixelRampCache 2007164144: a(n) GradientFillStyle class 0xbfc87f10 I LRUCache>at: 2012963616: a(n) LRUCache 0xbfc87f2c M GradientFillStyle>pixelRamp 2018529312: a(n) GradientFillStyle 0xbfc87f4c M BalloonEngine>registerFill: 2018659444: a(n) BalloonEngine 0xbfc87f74 M BalloonEngine>registerFills: 2018659444: a(n) BalloonEngine 0xbfc87f90 M BalloonEngine>registerFill:and: 2018659444: a(n) BalloonEngine 0xbfc87fb4 M BalloonEngine>drawRectangle:fill:borderWidth:borderColor:transform: 2018659444: a(n) BalloonEngine 0xbfc87fe8 M BalloonCanvas>drawRectangle:color:borderWidth:borderColor: 2018659252: a(n) BalloonCanvas 0xbfc88010 M BalloonCanvas>fillRectangle:fillStyle: 2018659252: a(n) BalloonCanvas 0xbfc88030 M FormCanvas>balloonFillRectangle:fillStyle: 2018611404: a(n) FormCanvas 0xbfc88054 M FormCanvas>fillRectangle:fillStyle: 2018611404: a(n) FormCanvas 0xbfc88074 M FormCanvas(Canvas)>fillRectangle:fillStyle:borderStyle: 2018611404: a(n) FormCanvas 0xbfc88098 M SystemWindow(Morph)>drawOn: 2014426088: a(n) SystemWindow 0xbfc880b4 M FormCanvas(Canvas)>draw: 2018611404: a(n) FormCanvas 0xbfc880d0 M FormCanvas(Canvas)>drawMorph: 2018611404: a(n) FormCanvas 0xbfc880f0 M [] in SystemWindow(Morph)>fullDrawOn: 2014426088: a(n) SystemWindow 0xbfc8810c M CornerRounder class>roundCornersOf:on:in:displayBlock:borderWidth:corners: 2007442196: a(n) CornerRounder class 0xbfc8813c M FormCanvas>roundCornersOf:in:during: 2018611404: a(n) FormCanvas 0xbfc88160 M FormCanvas(Canvas)>roundCornersOf:during: 2018611404: a(n) FormCanvas 0xbfc88180 M SystemWindow(Morph)>fullDrawOn: 2014426088: a(n) SystemWindow 0xbfc8819c M FormCanvas(Canvas)>fullDraw: 2018611404: a(n) FormCanvas 0xbfc881b8 M FormCanvas(Canvas)>fullDrawMorph: 2018611404: a(n) FormCanvas 0xbfc88208 M [] in WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: a(n) WorldState 0xbfc88240 I Rectangle>allAreasOutsideList:startingAt:do: 2017358104: a(n) Rectangle 0xbfc8826c I Rectangle>allAreasOutsideList:do: 2017358104: a(n) Rectangle 0xbfc882a8 M [] in WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: a(n) WorldState 0xbfc882cc M Array(SequenceableCollection)>do: 2018529764: a(n) Array 0xbfc882fc M WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: a(n) WorldState 0xbfc88334 M [] in WorldState>displayWorld:submorphs: 2001318316: a(n) WorldState 0xbfc8834c M FormCanvas>roundCornersOf:in:during: 2017358448: a(n) FormCanvas 0xbfc88370 M FormCanvas(Canvas)>roundCornersOf:during: 2017358448: a(n) FormCanvas 0xbfc88398 M WorldState>displayWorld:submorphs: 2001318316: a(n) WorldState 0xbfc883c0 I PasteUpMorph>privateOuterDisplayWorld 2001318568: a(n) PasteUpMorph 0xbfc883e0 I PasteUpMorph>displayWorld 2001318568: a(n) PasteUpMorph 0xbfc88404 I [] in WorldState>displayWorldSafely: 2001318316: a(n) WorldState 0xbfc88420 M BlockClosure>on:do: 2018529472: a(n) BlockClosure 0xbfc88440 M BlockClosure>ifError: 2018529472: a(n) BlockClosure 0xbfc88464 I WorldState>displayWorldSafely: 2001318316: a(n) WorldState 0xbfc88480 M PasteUpMorph>displayWorldSafely 2001318568: a(n) PasteUpMorph 0xbfc88498 M PasteUpMorph>install 2001318568: a(n) PasteUpMorph 0xbfc884c0 I AutoStart class>checkForPluginUpdate 2008299932: a(n) AutoStart class 0xbfc884e0 M AutoStart class>startUp: 2008299932: a(n) AutoStart class 0xbfc8850c M [] in SmalltalkImage>send:toClassesNamedIn:with: 2009624740: a(n) SmalltalkImage 0xbfc88534 I OrderedCollection>do: 2009661056: a(n) OrderedCollection 0xbfc8855c I SmalltalkImage>send:toClassesNamedIn:with: 2009624740: a(n) SmalltalkImage 0xbfc88588 I SmalltalkImage>processStartUpList: 2009624740: a(n) SmalltalkImage 0xbfc885b4 I SmalltalkImage>snapshot:andQuit:embedded: 2009624740: a(n) SmalltalkImage 2014606248 s SmalltalkImage>snapshot:andQuit: 2014606132 s TheWorldMainDockingBar>saveAndQuitSqueak 2014606040 s [] in MenuItemMorph>invokeWithEvent: 2014605924 s BlockClosure>ensure: 2014605832 s CursorWithMask(Cursor)>showWhile: 2014605632 s MenuItemMorph>invokeWithEvent: 2014605540 s MenuItemMorph>mouseUp: 2014605448 s MenuItemMorph>handleMouseUp: 2014605316 s MouseButtonEvent>sentTo: 2014605224 s MenuItemMorph(Morph)>handleEvent: 2014605132 s MorphicEventDispatcher>dispatchDefault:with: 2014605040 s MorphicEventDispatcher>dispatchEvent:with: 2014604948 s MenuItemMorph(Morph)>processEvent:using: 2014604856 s MorphicEventDispatcher>dispatchDefault:with: 2014604748 s MorphicEventDispatcher>dispatchEvent:with: 2014604616 s DockingBarMenuMorph(Morph)>processEvent:using: 2014604524 s DockingBarMenuMorph(Morph)>processEvent: 2014604432 s DockingBarMenuMorph(MenuMorph)>handleFocusEvent: 2014604340 s [] in HandMorph>sendFocusEvent:to:clear: 2014604248 s [] in PasteUpMorph>becomeActiveDuring: 2014604068 s BlockClosure>on:do: 2014603976 s PasteUpMorph>becomeActiveDuring: 2014603856 s HandMorph>sendFocusEvent:to:clear: 2014603764 s HandMorph>sendEvent:focus:clear: 2014603672 s HandMorph>sendMouseEvent: 2014603528 s HandMorph>handleEvent: 2014603180 s HandMorph>processEvents 2014603064 s [] in WorldState>doOneCycleNowFor: 2014602972 s Array(SequenceableCollection)>do: 2014602872 s WorldState>handsDo: 2014602780 s WorldState>doOneCycleNowFor: 2014602688 s WorldState>doOneCycleFor: 2014602596 s PasteUpMorph>doOneCycle 2010011832 s [] in Project class>spawnNewProcess 2010011700 s [] in BlockClosure>newProcess
Most recent primitives basicNew copyBits @ @ @ basicNew @ @ basicNew @ @ @ basicNew copyBits @ @ @ basicNew @ copyBits @ @ @ basicNew basicNew: at:put: @ copyBits @ @ @ basicNew @ @ @ basicNew shallowCopy new: @ @ new: at:put: at:put: at:put: at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ @ basicNew@ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ perform:with: @ @ perform:with: @ basicNew basicNew @ @ @ basicNew basicNew basicNew basicNew new: basicNew: basicNew primitiveSetBitBltPlugin: @ @ basicNew @ @ basicNew @ @ basicNew @ primitiveSetBitBltPlugin: @ @ basicNew @ @ basicNew @ @ basicNew @ @ wait at:put: signal primInitializeBuffer: primSetAALevel: primSetOffset: primSetClipRect: primSetEdgeTransform: primSetColorTransform: primSetEdgeTransform: primSetColorTransform: primGetDepth primSetDepth: new: at:put: at:put: basicNew: species stringHash:initialHash: fractionPart truncated fractionPart fractionPart truncated basicNew basicNew new: value: at:put: value: at:put: at:put: value:value: value:value: basicNew: basicNew: at:put: at:put: at:put: at:put: fractionPart truncated basicNew: at:put: at:put: at:put: at:put: fractionPart truncated basicNew: at:put: at:put: at:put: at:put: truncated truncated truncated truncated at:put: perform:with: truncated Aborted gokr@yoda:~/squeak$
On Mon, Jun 21, 2010 at 5:23 AM, Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
This is what happens when you are still using the LargeInteger prims. Execute
#(= bitAnd: bitOr: bitShift: bitXor: ~=) do:[:sel| LargePositiveInteger removeSelector: sel. ]. save the image, then you should be able to open without segfaulting.
There are a few other things also. Please file-in NecessaryImageChangesForCogToWork.1.cs from the image directory in the tarball or upgrade to the latest in trunk (i.e. Andreas added the changes from NecessaryImageChangesForCogToWork.1.cs to trunk over the weekend).
Cheers, Henry
On Jun 21, 2010, at 1:39 51PM, Göran Krampe wrote:
Howdy!
First: Super fun and cool! I am of course *very* happy to see Cog
released.
Now, over to some "testing"...
SIDENOTE: First btw I ran pystone.py with regular Python 2.6.5 on my
Lucid Lynx, then in the latest "regular" VM from Squeakvm.org. Result:
Python: 36k pystones Squeak: 45k pystones
So... the good ole VM is still a tad faster than CPython in that bench.
:)
Now, I wanted to try it out with Cogit. Trouble begins! :)
I am using the tar ball on a Lucid laptop.
- vm-sound-NAS does not compile! Lots of compile errors, probably due to
a new upstream NAS. So try to get rid of that plugin... is harder than I thought! I finally ended up hacking the configure script to "fail" on the compile check by trying to compile rubbish. ;)
- For some odd reason this will still create duplicate lines about NAS
in disabledPlugins.c, just manually remove one of them, fine. Tada! Got a VM binary.
- Fire it up on a *vanilla* Squeak4.1.1.image. BOOM, segfault. This is a
"full debug VM" per instructions in HowToBuild. Anyway, see all info below, and tell me if there is more you want. :)
Btw, is there some nice existing script to run to "collect data about the
box" that does uname etc?
regards, Göran
gokr@yoda:~/squeak$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU U2500 @ 1.20GHz stepping : 8 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm
bogomips : 2393.82 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management:
gokr@yoda:~/squeak$ gcc --version gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
gokr@yoda:~/squeak$ uname -a Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC
2010 i686 GNU/Linux
gokr@yoda:~/squeak$ squeak -version 3.9-7 #1 Mon Jun 21 13:20:28 CEST 2010 gcc 4.4.3 Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.11] Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC
2010 i686 GNU/Linux
plugin path: /usr/local/lib/squeak/3.9-7/ [default:
/usr/local/lib/squeak/3.9-7/]
gokr@yoda:~/squeak$ squeak Squeak4.1.1.image
((rcvr & 1)) || (addressCouldBeObj(rcvr)) 11334
Segmentation fault
Smalltalk stack dump: 0xbfc87e08 M GradientFillStyle>scaledAlphaMix:of:with: 2018669100: a(n)
GradientFillStyle
0xbfc87e5c M [] in GradientFillStyle>computePixelRampOfSize: 2018669100:
a(n) GradientFillStyle
0xbfc87e7c M SortedCollection(OrderedCollection)>do: 2018669424: a(n)
SortedCollection
0xbfc87eb4 I GradientFillStyle>computePixelRampOfSize: 2018669100: a(n)
GradientFillStyle
0xbfc87ed8 I [] in GradientFillStyle class>initPixelRampCache 2007164144:
a(n) GradientFillStyle class
0xbfc87f10 I LRUCache>at: 2012963616: a(n) LRUCache 0xbfc87f2c M GradientFillStyle>pixelRamp 2018529312: a(n)
GradientFillStyle
0xbfc87f4c M BalloonEngine>registerFill: 2018659444: a(n) BalloonEngine 0xbfc87f74 M BalloonEngine>registerFills: 2018659444: a(n) BalloonEngine 0xbfc87f90 M BalloonEngine>registerFill:and: 2018659444: a(n)
BalloonEngine
0xbfc87fb4 M
BalloonEngine>drawRectangle:fill:borderWidth:borderColor:transform: 2018659444: a(n) BalloonEngine
0xbfc87fe8 M BalloonCanvas>drawRectangle:color:borderWidth:borderColor:
2018659252: a(n) BalloonCanvas
0xbfc88010 M BalloonCanvas>fillRectangle:fillStyle: 2018659252: a(n)
BalloonCanvas
0xbfc88030 M FormCanvas>balloonFillRectangle:fillStyle: 2018611404: a(n)
FormCanvas
0xbfc88054 M FormCanvas>fillRectangle:fillStyle: 2018611404: a(n)
FormCanvas
0xbfc88074 M FormCanvas(Canvas)>fillRectangle:fillStyle:borderStyle:
2018611404: a(n) FormCanvas
0xbfc88098 M SystemWindow(Morph)>drawOn: 2014426088: a(n) SystemWindow 0xbfc880b4 M FormCanvas(Canvas)>draw: 2018611404: a(n) FormCanvas 0xbfc880d0 M FormCanvas(Canvas)>drawMorph: 2018611404: a(n) FormCanvas 0xbfc880f0 M [] in SystemWindow(Morph)>fullDrawOn: 2014426088: a(n)
SystemWindow
0xbfc8810c M CornerRounder
class>roundCornersOf:on:in:displayBlock:borderWidth:corners: 2007442196: a(n) CornerRounder class
0xbfc8813c M FormCanvas>roundCornersOf:in:during: 2018611404: a(n)
FormCanvas
0xbfc88160 M FormCanvas(Canvas)>roundCornersOf:during: 2018611404: a(n)
FormCanvas
0xbfc88180 M SystemWindow(Morph)>fullDrawOn: 2014426088: a(n)
SystemWindow
0xbfc8819c M FormCanvas(Canvas)>fullDraw: 2018611404: a(n) FormCanvas 0xbfc881b8 M FormCanvas(Canvas)>fullDrawMorph: 2018611404: a(n)
FormCanvas
0xbfc88208 M [] in WorldState>drawWorld:submorphs:invalidAreasOn:
2001318316: a(n) WorldState
0xbfc88240 I Rectangle>allAreasOutsideList:startingAt:do: 2017358104:
a(n) Rectangle
0xbfc8826c I Rectangle>allAreasOutsideList:do: 2017358104: a(n) Rectangle 0xbfc882a8 M [] in WorldState>drawWorld:submorphs:invalidAreasOn:
2001318316: a(n) WorldState
0xbfc882cc M Array(SequenceableCollection)>do: 2018529764: a(n) Array 0xbfc882fc M WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316:
a(n) WorldState
0xbfc88334 M [] in WorldState>displayWorld:submorphs: 2001318316: a(n)
WorldState
0xbfc8834c M FormCanvas>roundCornersOf:in:during: 2017358448: a(n)
FormCanvas
0xbfc88370 M FormCanvas(Canvas)>roundCornersOf:during: 2017358448: a(n)
FormCanvas
0xbfc88398 M WorldState>displayWorld:submorphs: 2001318316: a(n)
WorldState
0xbfc883c0 I PasteUpMorph>privateOuterDisplayWorld 2001318568: a(n)
PasteUpMorph
0xbfc883e0 I PasteUpMorph>displayWorld 2001318568: a(n) PasteUpMorph 0xbfc88404 I [] in WorldState>displayWorldSafely: 2001318316: a(n)
WorldState
0xbfc88420 M BlockClosure>on:do: 2018529472: a(n) BlockClosure 0xbfc88440 M BlockClosure>ifError: 2018529472: a(n) BlockClosure 0xbfc88464 I WorldState>displayWorldSafely: 2001318316: a(n) WorldState 0xbfc88480 M PasteUpMorph>displayWorldSafely 2001318568: a(n)
PasteUpMorph
0xbfc88498 M PasteUpMorph>install 2001318568: a(n) PasteUpMorph 0xbfc884c0 I AutoStart class>checkForPluginUpdate 2008299932: a(n)
AutoStart class
0xbfc884e0 M AutoStart class>startUp: 2008299932: a(n) AutoStart class 0xbfc8850c M [] in SmalltalkImage>send:toClassesNamedIn:with: 2009624740:
a(n) SmalltalkImage
0xbfc88534 I OrderedCollection>do: 2009661056: a(n) OrderedCollection 0xbfc8855c I SmalltalkImage>send:toClassesNamedIn:with: 2009624740: a(n)
SmalltalkImage
0xbfc88588 I SmalltalkImage>processStartUpList: 2009624740: a(n)
SmalltalkImage
0xbfc885b4 I SmalltalkImage>snapshot:andQuit:embedded: 2009624740: a(n)
SmalltalkImage
2014606248 s SmalltalkImage>snapshot:andQuit: 2014606132 s TheWorldMainDockingBar>saveAndQuitSqueak 2014606040 s [] in MenuItemMorph>invokeWithEvent: 2014605924 s BlockClosure>ensure: 2014605832 s CursorWithMask(Cursor)>showWhile: 2014605632 s MenuItemMorph>invokeWithEvent: 2014605540 s MenuItemMorph>mouseUp: 2014605448 s MenuItemMorph>handleMouseUp: 2014605316 s MouseButtonEvent>sentTo: 2014605224 s MenuItemMorph(Morph)>handleEvent: 2014605132 s MorphicEventDispatcher>dispatchDefault:with: 2014605040 s MorphicEventDispatcher>dispatchEvent:with: 2014604948 s MenuItemMorph(Morph)>processEvent:using: 2014604856 s MorphicEventDispatcher>dispatchDefault:with: 2014604748 s MorphicEventDispatcher>dispatchEvent:with: 2014604616 s DockingBarMenuMorph(Morph)>processEvent:using: 2014604524 s DockingBarMenuMorph(Morph)>processEvent: 2014604432 s DockingBarMenuMorph(MenuMorph)>handleFocusEvent: 2014604340 s [] in HandMorph>sendFocusEvent:to:clear: 2014604248 s [] in PasteUpMorph>becomeActiveDuring: 2014604068 s BlockClosure>on:do: 2014603976 s PasteUpMorph>becomeActiveDuring: 2014603856 s HandMorph>sendFocusEvent:to:clear: 2014603764 s HandMorph>sendEvent:focus:clear: 2014603672 s HandMorph>sendMouseEvent: 2014603528 s HandMorph>handleEvent: 2014603180 s HandMorph>processEvents 2014603064 s [] in WorldState>doOneCycleNowFor: 2014602972 s Array(SequenceableCollection)>do: 2014602872 s WorldState>handsDo: 2014602780 s WorldState>doOneCycleNowFor: 2014602688 s WorldState>doOneCycleFor: 2014602596 s PasteUpMorph>doOneCycle 2010011832 s [] in Project class>spawnNewProcess 2010011700 s [] in BlockClosure>newProcess
Most recent primitives basicNew copyBits @ @ @ basicNew @ @ basicNew @ @ @ basicNew copyBits @ @ @ basicNew @ copyBits @ @ @ basicNew basicNew: at:put: @ copyBits @ @ @ basicNew @ @ @ basicNew shallowCopy new: @ @ new: at:put: at:put: at:put: at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ @ basicNew@ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ perform:with: @ @ perform:with: @ basicNew basicNew @ @ @ basicNew basicNew basicNew basicNew new: basicNew: basicNew primitiveSetBitBltPlugin: @ @ basicNew @ @ basicNew @ @ basicNew @ primitiveSetBitBltPlugin: @ @ basicNew @ @ basicNew @ @ basicNew @ @ wait at:put: signal primInitializeBuffer: primSetAALevel: primSetOffset: primSetClipRect: primSetEdgeTransform: primSetColorTransform: primSetEdgeTransform: primSetColorTransform: primGetDepth primSetDepth: new: at:put: at:put: basicNew: species stringHash:initialHash: fractionPart truncated fractionPart fractionPart truncated basicNew basicNew new: value: at:put: value: at:put: at:put: value:value: value:value: basicNew: basicNew: at:put: at:put: at:put: at:put: fractionPart truncated basicNew: at:put: at:put: at:put: at:put: fractionPart truncated basicNew: at:put: at:put: at:put: at:put: truncated truncated truncated truncated at:put: perform:with: truncated Aborted gokr@yoda:~/squeak$
There are a few other things also. Please file-in NecessaryImageChangesForCogToWork.1.cs from the image directory in the tarball or upgrade to the latest in trunk (i.e. Andreas added the changes from NecessaryImageChangesForCogToWork.1.cs to trunk over the weekend).
eliot do you know whether these changes can be integrated and the images will work on the different Cog and nonCog
Stef
Cheers, Henry
On Jun 21, 2010, at 1:39 51PM, Göran Krampe wrote:
Howdy!
First: Super fun and cool! I am of course *very* happy to see Cog released.
Now, over to some "testing"...
SIDENOTE: First btw I ran pystone.py with regular Python 2.6.5 on my Lucid Lynx, then in the latest "regular" VM from Squeakvm.org. Result:
Python: 36k pystones Squeak: 45k pystones
So... the good ole VM is still a tad faster than CPython in that bench. :)
Now, I wanted to try it out with Cogit. Trouble begins! :)
I am using the tar ball on a Lucid laptop.
vm-sound-NAS does not compile! Lots of compile errors, probably due to a new upstream NAS. So try to get rid of that plugin... is harder than I thought! I finally ended up hacking the configure script to "fail" on the compile check by trying to compile rubbish. ;)
For some odd reason this will still create duplicate lines about NAS in disabledPlugins.c, just manually remove one of them, fine. Tada! Got a VM binary.
Fire it up on a *vanilla* Squeak4.1.1.image. BOOM, segfault. This is a "full debug VM" per instructions in HowToBuild. Anyway, see all info below, and tell me if there is more you want. :)
Btw, is there some nice existing script to run to "collect data about the box" that does uname etc?
regards, Göran
gokr@yoda:~/squeak$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU U2500 @ 1.20GHz stepping : 8 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm bogomips : 2393.82 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management:
gokr@yoda:~/squeak$ gcc --version gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gokr@yoda:~/squeak$ uname -a Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC 2010 i686 GNU/Linux
gokr@yoda:~/squeak$ squeak -version 3.9-7 #1 Mon Jun 21 13:20:28 CEST 2010 gcc 4.4.3 Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.11] Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC 2010 i686 GNU/Linux plugin path: /usr/local/lib/squeak/3.9-7/ [default: /usr/local/lib/squeak/3.9-7/]
gokr@yoda:~/squeak$ squeak Squeak4.1.1.image
((rcvr & 1)) || (addressCouldBeObj(rcvr)) 11334
Segmentation fault
Smalltalk stack dump: 0xbfc87e08 M GradientFillStyle>scaledAlphaMix:of:with: 2018669100: a(n) GradientFillStyle 0xbfc87e5c M [] in GradientFillStyle>computePixelRampOfSize: 2018669100: a(n) GradientFillStyle 0xbfc87e7c M SortedCollection(OrderedCollection)>do: 2018669424: a(n) SortedCollection 0xbfc87eb4 I GradientFillStyle>computePixelRampOfSize: 2018669100: a(n) GradientFillStyle 0xbfc87ed8 I [] in GradientFillStyle class>initPixelRampCache 2007164144: a(n) GradientFillStyle class 0xbfc87f10 I LRUCache>at: 2012963616: a(n) LRUCache 0xbfc87f2c M GradientFillStyle>pixelRamp 2018529312: a(n) GradientFillStyle 0xbfc87f4c M BalloonEngine>registerFill: 2018659444: a(n) BalloonEngine 0xbfc87f74 M BalloonEngine>registerFills: 2018659444: a(n) BalloonEngine 0xbfc87f90 M BalloonEngine>registerFill:and: 2018659444: a(n) BalloonEngine 0xbfc87fb4 M BalloonEngine>drawRectangle:fill:borderWidth:borderColor:transform: 2018659444: a(n) BalloonEngine 0xbfc87fe8 M BalloonCanvas>drawRectangle:color:borderWidth:borderColor: 2018659252: a(n) BalloonCanvas 0xbfc88010 M BalloonCanvas>fillRectangle:fillStyle: 2018659252: a(n) BalloonCanvas 0xbfc88030 M FormCanvas>balloonFillRectangle:fillStyle: 2018611404: a(n) FormCanvas 0xbfc88054 M FormCanvas>fillRectangle:fillStyle: 2018611404: a(n) FormCanvas 0xbfc88074 M FormCanvas(Canvas)>fillRectangle:fillStyle:borderStyle: 2018611404: a(n) FormCanvas 0xbfc88098 M SystemWindow(Morph)>drawOn: 2014426088: a(n) SystemWindow 0xbfc880b4 M FormCanvas(Canvas)>draw: 2018611404: a(n) FormCanvas 0xbfc880d0 M FormCanvas(Canvas)>drawMorph: 2018611404: a(n) FormCanvas 0xbfc880f0 M [] in SystemWindow(Morph)>fullDrawOn: 2014426088: a(n) SystemWindow 0xbfc8810c M CornerRounder class>roundCornersOf:on:in:displayBlock:borderWidth:corners: 2007442196: a(n) CornerRounder class 0xbfc8813c M FormCanvas>roundCornersOf:in:during: 2018611404: a(n) FormCanvas 0xbfc88160 M FormCanvas(Canvas)>roundCornersOf:during: 2018611404: a(n) FormCanvas 0xbfc88180 M SystemWindow(Morph)>fullDrawOn: 2014426088: a(n) SystemWindow 0xbfc8819c M FormCanvas(Canvas)>fullDraw: 2018611404: a(n) FormCanvas 0xbfc881b8 M FormCanvas(Canvas)>fullDrawMorph: 2018611404: a(n) FormCanvas 0xbfc88208 M [] in WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: a(n) WorldState 0xbfc88240 I Rectangle>allAreasOutsideList:startingAt:do: 2017358104: a(n) Rectangle 0xbfc8826c I Rectangle>allAreasOutsideList:do: 2017358104: a(n) Rectangle 0xbfc882a8 M [] in WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: a(n) WorldState 0xbfc882cc M Array(SequenceableCollection)>do: 2018529764: a(n) Array 0xbfc882fc M WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: a(n) WorldState 0xbfc88334 M [] in WorldState>displayWorld:submorphs: 2001318316: a(n) WorldState 0xbfc8834c M FormCanvas>roundCornersOf:in:during: 2017358448: a(n) FormCanvas 0xbfc88370 M FormCanvas(Canvas)>roundCornersOf:during: 2017358448: a(n) FormCanvas 0xbfc88398 M WorldState>displayWorld:submorphs: 2001318316: a(n) WorldState 0xbfc883c0 I PasteUpMorph>privateOuterDisplayWorld 2001318568: a(n) PasteUpMorph 0xbfc883e0 I PasteUpMorph>displayWorld 2001318568: a(n) PasteUpMorph 0xbfc88404 I [] in WorldState>displayWorldSafely: 2001318316: a(n) WorldState 0xbfc88420 M BlockClosure>on:do: 2018529472: a(n) BlockClosure 0xbfc88440 M BlockClosure>ifError: 2018529472: a(n) BlockClosure 0xbfc88464 I WorldState>displayWorldSafely: 2001318316: a(n) WorldState 0xbfc88480 M PasteUpMorph>displayWorldSafely 2001318568: a(n) PasteUpMorph 0xbfc88498 M PasteUpMorph>install 2001318568: a(n) PasteUpMorph 0xbfc884c0 I AutoStart class>checkForPluginUpdate 2008299932: a(n) AutoStart class 0xbfc884e0 M AutoStart class>startUp: 2008299932: a(n) AutoStart class 0xbfc8850c M [] in SmalltalkImage>send:toClassesNamedIn:with: 2009624740: a(n) SmalltalkImage 0xbfc88534 I OrderedCollection>do: 2009661056: a(n) OrderedCollection 0xbfc8855c I SmalltalkImage>send:toClassesNamedIn:with: 2009624740: a(n) SmalltalkImage 0xbfc88588 I SmalltalkImage>processStartUpList: 2009624740: a(n) SmalltalkImage 0xbfc885b4 I SmalltalkImage>snapshot:andQuit:embedded: 2009624740: a(n) SmalltalkImage 2014606248 s SmalltalkImage>snapshot:andQuit: 2014606132 s TheWorldMainDockingBar>saveAndQuitSqueak 2014606040 s [] in MenuItemMorph>invokeWithEvent: 2014605924 s BlockClosure>ensure: 2014605832 s CursorWithMask(Cursor)>showWhile: 2014605632 s MenuItemMorph>invokeWithEvent: 2014605540 s MenuItemMorph>mouseUp: 2014605448 s MenuItemMorph>handleMouseUp: 2014605316 s MouseButtonEvent>sentTo: 2014605224 s MenuItemMorph(Morph)>handleEvent: 2014605132 s MorphicEventDispatcher>dispatchDefault:with: 2014605040 s MorphicEventDispatcher>dispatchEvent:with: 2014604948 s MenuItemMorph(Morph)>processEvent:using: 2014604856 s MorphicEventDispatcher>dispatchDefault:with: 2014604748 s MorphicEventDispatcher>dispatchEvent:with: 2014604616 s DockingBarMenuMorph(Morph)>processEvent:using: 2014604524 s DockingBarMenuMorph(Morph)>processEvent: 2014604432 s DockingBarMenuMorph(MenuMorph)>handleFocusEvent: 2014604340 s [] in HandMorph>sendFocusEvent:to:clear: 2014604248 s [] in PasteUpMorph>becomeActiveDuring: 2014604068 s BlockClosure>on:do: 2014603976 s PasteUpMorph>becomeActiveDuring: 2014603856 s HandMorph>sendFocusEvent:to:clear: 2014603764 s HandMorph>sendEvent:focus:clear: 2014603672 s HandMorph>sendMouseEvent: 2014603528 s HandMorph>handleEvent: 2014603180 s HandMorph>processEvents 2014603064 s [] in WorldState>doOneCycleNowFor: 2014602972 s Array(SequenceableCollection)>do: 2014602872 s WorldState>handsDo: 2014602780 s WorldState>doOneCycleNowFor: 2014602688 s WorldState>doOneCycleFor: 2014602596 s PasteUpMorph>doOneCycle 2010011832 s [] in Project class>spawnNewProcess 2010011700 s [] in BlockClosure>newProcess
Most recent primitives basicNew copyBits @ @ @ basicNew @ @ basicNew @ @ @ basicNew copyBits @ @ @ basicNew @ copyBits @ @ @ basicNew basicNew: at:put: @ copyBits @ @ @ basicNew @ @ @ basicNew shallowCopy new: @ @ new: at:put: at:put: at:put: at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ @ basicNew@ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ perform:with: @ @ perform:with: @ basicNew basicNew @ @ @ basicNew basicNew basicNew basicNew new: basicNew: basicNew primitiveSetBitBltPlugin: @ @ basicNew @ @ basicNew @ @ basicNew @ primitiveSetBitBltPlugin: @ @ basicNew @ @ basicNew @ @ basicNew @ @ wait at:put: signal primInitializeBuffer: primSetAALevel: primSetOffset: primSetClipRect: primSetEdgeTransform: primSetColorTransform: primSetEdgeTransform: primSetColorTransform: primGetDepth primSetDepth: new: at:put: at:put: basicNew: species stringHash:initialHash: fractionPart truncated fractionPart fractionPart truncated basicNew basicNew new: value: at:put: value: at:put: at:put: value:value: value:value: basicNew: basicNew: at:put: at:put: at:put: at:put: fractionPart truncated basicNew: at:put: at:put: at:put: at:put: fractionPart truncated basicNew: at:put: at:put: at:put: at:put: truncated truncated truncated truncated at:put: perform:with: truncated Aborted gokr@yoda:~/squeak$
On 21.06.2010 21:27, stephane ducasse wrote:
There are a few other things also. Please file-in NecessaryImageChangesForCogToWork.1.cs from the image directory in the tarball or upgrade to the latest in trunk (i.e. Andreas added the changes from NecessaryImageChangesForCogToWork.1.cs to trunk over the weekend).
eliot do you know whether these changes can be integrated and the images will work on the different Cog and nonCog
Stef
Issues 2579 - 2581 on the bug tracker cover the changes to Float access in Pharo. An "old" VW will also run without the LargeInteger primitives, albeit slower. recreateSpecialObjectsArray is never backwards-incompatible (at least not for reasonable values of backwards-compatible).
So basically, yes.
Cheers, Henry
On Mon, Jun 21, 2010 at 12:27 PM, stephane ducasse < stephane.ducasse@gmail.com> wrote:
There are a few other things also. Please file-in
NecessaryImageChangesForCogToWork.1.cs from the image directory in the tarball or upgrade to the latest in trunk (i.e. Andreas added the changes from NecessaryImageChangesForCogToWork.1.cs to trunk over the weekend).
eliot do you know whether these changes can be integrated and the images will work on the different Cog and nonCog
These are "carefully crafted" to be backward-compatible. They will /not/ break an image for older VMs. There are three sets of changes:
1. remove primitives in LargePositiveInteger. These will make images slightly slower for certain benchmarks but won't break anything. 2. add special primitives for Float>>basicAt: at: basicAt:put: & at:put: that call super if they fail. They will fail on older VMs, hence these will make images slightly slower for certain benchmarks but won't break anything. 3. a new version of recreateSpecialObjectsArray that does not recreate the Character table. This will have no effect except for Cog, where it allows the VM to inline Character table access in the at: primitive.
Stef
Cheers, Henry
On Jun 21, 2010, at 1:39 51PM, Göran Krampe wrote:
Howdy!
First: Super fun and cool! I am of course *very* happy to see Cog
released.
Now, over to some "testing"...
SIDENOTE: First btw I ran pystone.py with regular Python 2.6.5 on my
Lucid Lynx, then in the latest "regular" VM from Squeakvm.org. Result:
Python: 36k pystones Squeak: 45k pystones
So... the good ole VM is still a tad faster than CPython in that bench.
:)
Now, I wanted to try it out with Cogit. Trouble begins! :)
I am using the tar ball on a Lucid laptop.
- vm-sound-NAS does not compile! Lots of compile errors, probably due
to a new upstream NAS. So try to get rid of that plugin... is harder than I thought! I finally ended up hacking the configure script to "fail" on the compile check by trying to compile rubbish. ;)
- For some odd reason this will still create duplicate lines about NAS
in disabledPlugins.c, just manually remove one of them, fine. Tada! Got a VM binary.
- Fire it up on a *vanilla* Squeak4.1.1.image. BOOM, segfault. This is
a "full debug VM" per instructions in HowToBuild. Anyway, see all info below, and tell me if there is more you want. :)
Btw, is there some nice existing script to run to "collect data about
the box" that does uname etc?
regards, Göran
gokr@yoda:~/squeak$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU U2500 @ 1.20GHz stepping : 8 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm
bogomips : 2393.82 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management:
gokr@yoda:~/squeak$ gcc --version gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
gokr@yoda:~/squeak$ uname -a Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC
2010 i686 GNU/Linux
gokr@yoda:~/squeak$ squeak -version 3.9-7 #1 Mon Jun 21 13:20:28 CEST 2010 gcc 4.4.3 Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.11] Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC
2010 i686 GNU/Linux
plugin path: /usr/local/lib/squeak/3.9-7/ [default:
/usr/local/lib/squeak/3.9-7/]
gokr@yoda:~/squeak$ squeak Squeak4.1.1.image
((rcvr & 1)) || (addressCouldBeObj(rcvr)) 11334
Segmentation fault
Smalltalk stack dump: 0xbfc87e08 M GradientFillStyle>scaledAlphaMix:of:with: 2018669100: a(n)
GradientFillStyle
0xbfc87e5c M [] in GradientFillStyle>computePixelRampOfSize:
2018669100: a(n) GradientFillStyle
0xbfc87e7c M SortedCollection(OrderedCollection)>do: 2018669424: a(n)
SortedCollection
0xbfc87eb4 I GradientFillStyle>computePixelRampOfSize: 2018669100: a(n)
GradientFillStyle
0xbfc87ed8 I [] in GradientFillStyle class>initPixelRampCache
2007164144: a(n) GradientFillStyle class
0xbfc87f10 I LRUCache>at: 2012963616: a(n) LRUCache 0xbfc87f2c M GradientFillStyle>pixelRamp 2018529312: a(n)
GradientFillStyle
0xbfc87f4c M BalloonEngine>registerFill: 2018659444: a(n) BalloonEngine 0xbfc87f74 M BalloonEngine>registerFills: 2018659444: a(n)
BalloonEngine
0xbfc87f90 M BalloonEngine>registerFill:and: 2018659444: a(n)
BalloonEngine
0xbfc87fb4 M
BalloonEngine>drawRectangle:fill:borderWidth:borderColor:transform: 2018659444: a(n) BalloonEngine
0xbfc87fe8 M BalloonCanvas>drawRectangle:color:borderWidth:borderColor:
2018659252: a(n) BalloonCanvas
0xbfc88010 M BalloonCanvas>fillRectangle:fillStyle: 2018659252: a(n)
BalloonCanvas
0xbfc88030 M FormCanvas>balloonFillRectangle:fillStyle: 2018611404:
a(n) FormCanvas
0xbfc88054 M FormCanvas>fillRectangle:fillStyle: 2018611404: a(n)
FormCanvas
0xbfc88074 M FormCanvas(Canvas)>fillRectangle:fillStyle:borderStyle:
2018611404: a(n) FormCanvas
0xbfc88098 M SystemWindow(Morph)>drawOn: 2014426088: a(n) SystemWindow 0xbfc880b4 M FormCanvas(Canvas)>draw: 2018611404: a(n) FormCanvas 0xbfc880d0 M FormCanvas(Canvas)>drawMorph: 2018611404: a(n) FormCanvas 0xbfc880f0 M [] in SystemWindow(Morph)>fullDrawOn: 2014426088: a(n)
SystemWindow
0xbfc8810c M CornerRounder
class>roundCornersOf:on:in:displayBlock:borderWidth:corners: 2007442196: a(n) CornerRounder class
0xbfc8813c M FormCanvas>roundCornersOf:in:during: 2018611404: a(n)
FormCanvas
0xbfc88160 M FormCanvas(Canvas)>roundCornersOf:during: 2018611404: a(n)
FormCanvas
0xbfc88180 M SystemWindow(Morph)>fullDrawOn: 2014426088: a(n)
SystemWindow
0xbfc8819c M FormCanvas(Canvas)>fullDraw: 2018611404: a(n) FormCanvas 0xbfc881b8 M FormCanvas(Canvas)>fullDrawMorph: 2018611404: a(n)
FormCanvas
0xbfc88208 M [] in WorldState>drawWorld:submorphs:invalidAreasOn:
2001318316: a(n) WorldState
0xbfc88240 I Rectangle>allAreasOutsideList:startingAt:do: 2017358104:
a(n) Rectangle
0xbfc8826c I Rectangle>allAreasOutsideList:do: 2017358104: a(n)
Rectangle
0xbfc882a8 M [] in WorldState>drawWorld:submorphs:invalidAreasOn:
2001318316: a(n) WorldState
0xbfc882cc M Array(SequenceableCollection)>do: 2018529764: a(n) Array 0xbfc882fc M WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316:
a(n) WorldState
0xbfc88334 M [] in WorldState>displayWorld:submorphs: 2001318316: a(n)
WorldState
0xbfc8834c M FormCanvas>roundCornersOf:in:during: 2017358448: a(n)
FormCanvas
0xbfc88370 M FormCanvas(Canvas)>roundCornersOf:during: 2017358448: a(n)
FormCanvas
0xbfc88398 M WorldState>displayWorld:submorphs: 2001318316: a(n)
WorldState
0xbfc883c0 I PasteUpMorph>privateOuterDisplayWorld 2001318568: a(n)
PasteUpMorph
0xbfc883e0 I PasteUpMorph>displayWorld 2001318568: a(n) PasteUpMorph 0xbfc88404 I [] in WorldState>displayWorldSafely: 2001318316: a(n)
WorldState
0xbfc88420 M BlockClosure>on:do: 2018529472: a(n) BlockClosure 0xbfc88440 M BlockClosure>ifError: 2018529472: a(n) BlockClosure 0xbfc88464 I WorldState>displayWorldSafely: 2001318316: a(n) WorldState 0xbfc88480 M PasteUpMorph>displayWorldSafely 2001318568: a(n)
PasteUpMorph
0xbfc88498 M PasteUpMorph>install 2001318568: a(n) PasteUpMorph 0xbfc884c0 I AutoStart class>checkForPluginUpdate 2008299932: a(n)
AutoStart class
0xbfc884e0 M AutoStart class>startUp: 2008299932: a(n) AutoStart class 0xbfc8850c M [] in SmalltalkImage>send:toClassesNamedIn:with:
2009624740: a(n) SmalltalkImage
0xbfc88534 I OrderedCollection>do: 2009661056: a(n) OrderedCollection 0xbfc8855c I SmalltalkImage>send:toClassesNamedIn:with: 2009624740:
a(n) SmalltalkImage
0xbfc88588 I SmalltalkImage>processStartUpList: 2009624740: a(n)
SmalltalkImage
0xbfc885b4 I SmalltalkImage>snapshot:andQuit:embedded: 2009624740: a(n)
SmalltalkImage
2014606248 s SmalltalkImage>snapshot:andQuit: 2014606132 s TheWorldMainDockingBar>saveAndQuitSqueak 2014606040 s [] in MenuItemMorph>invokeWithEvent: 2014605924 s BlockClosure>ensure: 2014605832 s CursorWithMask(Cursor)>showWhile: 2014605632 s MenuItemMorph>invokeWithEvent: 2014605540 s MenuItemMorph>mouseUp: 2014605448 s MenuItemMorph>handleMouseUp: 2014605316 s MouseButtonEvent>sentTo: 2014605224 s MenuItemMorph(Morph)>handleEvent: 2014605132 s MorphicEventDispatcher>dispatchDefault:with: 2014605040 s MorphicEventDispatcher>dispatchEvent:with: 2014604948 s MenuItemMorph(Morph)>processEvent:using: 2014604856 s MorphicEventDispatcher>dispatchDefault:with: 2014604748 s MorphicEventDispatcher>dispatchEvent:with: 2014604616 s DockingBarMenuMorph(Morph)>processEvent:using: 2014604524 s DockingBarMenuMorph(Morph)>processEvent: 2014604432 s DockingBarMenuMorph(MenuMorph)>handleFocusEvent: 2014604340 s [] in HandMorph>sendFocusEvent:to:clear: 2014604248 s [] in PasteUpMorph>becomeActiveDuring: 2014604068 s BlockClosure>on:do: 2014603976 s PasteUpMorph>becomeActiveDuring: 2014603856 s HandMorph>sendFocusEvent:to:clear: 2014603764 s HandMorph>sendEvent:focus:clear: 2014603672 s HandMorph>sendMouseEvent: 2014603528 s HandMorph>handleEvent: 2014603180 s HandMorph>processEvents 2014603064 s [] in WorldState>doOneCycleNowFor: 2014602972 s Array(SequenceableCollection)>do: 2014602872 s WorldState>handsDo: 2014602780 s WorldState>doOneCycleNowFor: 2014602688 s WorldState>doOneCycleFor: 2014602596 s PasteUpMorph>doOneCycle 2010011832 s [] in Project class>spawnNewProcess 2010011700 s [] in BlockClosure>newProcess
Most recent primitives basicNew copyBits @ @ @ basicNew @ @ basicNew @ @ @ basicNew copyBits @ @ @ basicNew @ copyBits @ @ @ basicNew basicNew: at:put: @ copyBits @ @ @ basicNew @ @ @ basicNew shallowCopy new: @ @ new: at:put: at:put: at:put: at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ @ basicNew@ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ perform:with: @ @ perform:with: @ basicNew basicNew @ @ @ basicNew basicNew basicNew basicNew new: basicNew: basicNew primitiveSetBitBltPlugin: @ @ basicNew @ @ basicNew @ @ basicNew @ primitiveSetBitBltPlugin: @ @ basicNew @ @ basicNew @ @ basicNew @ @ wait at:put: signal primInitializeBuffer: primSetAALevel: primSetOffset: primSetClipRect: primSetEdgeTransform: primSetColorTransform: primSetEdgeTransform: primSetColorTransform: primGetDepth primSetDepth: new: at:put: at:put: basicNew: species stringHash:initialHash: fractionPart truncated fractionPart fractionPart truncated basicNew basicNew new: value: at:put: value: at:put: at:put: value:value: value:value: basicNew: basicNew: at:put: at:put: at:put: at:put: fractionPart truncated basicNew: at:put: at:put: at:put: at:put: fractionPart truncated basicNew: at:put: at:put: at:put: at:put: truncated truncated truncated truncated at:put: perform:with: truncated Aborted gokr@yoda:~/squeak$
thanks for educating me :)
On Jun 21, 2010, at 9:34 PM, Eliot Miranda wrote:
On Mon, Jun 21, 2010 at 12:27 PM, stephane ducasse stephane.ducasse@gmail.com wrote:
There are a few other things also. Please file-in NecessaryImageChangesForCogToWork.1.cs from the image directory in the tarball or upgrade to the latest in trunk (i.e. Andreas added the changes from NecessaryImageChangesForCogToWork.1.cs to trunk over the weekend).
eliot do you know whether these changes can be integrated and the images will work on the different Cog and nonCog
These are "carefully crafted" to be backward-compatible. They will /not/ break an image for older VMs. There are three sets of changes:
- remove primitives in LargePositiveInteger. These will make images slightly slower for certain benchmarks but won't break anything.
- add special primitives for Float>>basicAt: at: basicAt:put: & at:put: that call super if they fail. They will fail on older VMs, hence these will make images slightly slower for certain benchmarks but won't break anything.
- a new version of recreateSpecialObjectsArray that does not recreate the Character table. This will have no effect except for Cog, where it allows the VM to inline Character table access in the at: primitive.
Stef
Cheers, Henry
On Jun 21, 2010, at 1:39 51PM, Göran Krampe wrote:
Howdy!
First: Super fun and cool! I am of course *very* happy to see Cog released.
Now, over to some "testing"...
SIDENOTE: First btw I ran pystone.py with regular Python 2.6.5 on my Lucid Lynx, then in the latest "regular" VM from Squeakvm.org. Result:
Python: 36k pystones Squeak: 45k pystones
So... the good ole VM is still a tad faster than CPython in that bench. :)
Now, I wanted to try it out with Cogit. Trouble begins! :)
I am using the tar ball on a Lucid laptop.
vm-sound-NAS does not compile! Lots of compile errors, probably due to a new upstream NAS. So try to get rid of that plugin... is harder than I thought! I finally ended up hacking the configure script to "fail" on the compile check by trying to compile rubbish. ;)
For some odd reason this will still create duplicate lines about NAS in disabledPlugins.c, just manually remove one of them, fine. Tada! Got a VM binary.
Fire it up on a *vanilla* Squeak4.1.1.image. BOOM, segfault. This is a "full debug VM" per instructions in HowToBuild. Anyway, see all info below, and tell me if there is more you want. :)
Btw, is there some nice existing script to run to "collect data about the box" that does uname etc?
regards, Göran
gokr@yoda:~/squeak$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU U2500 @ 1.20GHz stepping : 8 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm bogomips : 2393.82 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management:
gokr@yoda:~/squeak$ gcc --version gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gokr@yoda:~/squeak$ uname -a Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC 2010 i686 GNU/Linux
gokr@yoda:~/squeak$ squeak -version 3.9-7 #1 Mon Jun 21 13:20:28 CEST 2010 gcc 4.4.3 Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.11] Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC 2010 i686 GNU/Linux plugin path: /usr/local/lib/squeak/3.9-7/ [default: /usr/local/lib/squeak/3.9-7/]
gokr@yoda:~/squeak$ squeak Squeak4.1.1.image
((rcvr & 1)) || (addressCouldBeObj(rcvr)) 11334
Segmentation fault
Smalltalk stack dump: 0xbfc87e08 M GradientFillStyle>scaledAlphaMix:of:with: 2018669100: a(n) GradientFillStyle 0xbfc87e5c M [] in GradientFillStyle>computePixelRampOfSize: 2018669100: a(n) GradientFillStyle 0xbfc87e7c M SortedCollection(OrderedCollection)>do: 2018669424: a(n) SortedCollection 0xbfc87eb4 I GradientFillStyle>computePixelRampOfSize: 2018669100: a(n) GradientFillStyle 0xbfc87ed8 I [] in GradientFillStyle class>initPixelRampCache 2007164144: a(n) GradientFillStyle class 0xbfc87f10 I LRUCache>at: 2012963616: a(n) LRUCache 0xbfc87f2c M GradientFillStyle>pixelRamp 2018529312: a(n) GradientFillStyle 0xbfc87f4c M BalloonEngine>registerFill: 2018659444: a(n) BalloonEngine 0xbfc87f74 M BalloonEngine>registerFills: 2018659444: a(n) BalloonEngine 0xbfc87f90 M BalloonEngine>registerFill:and: 2018659444: a(n) BalloonEngine 0xbfc87fb4 M BalloonEngine>drawRectangle:fill:borderWidth:borderColor:transform: 2018659444: a(n) BalloonEngine 0xbfc87fe8 M BalloonCanvas>drawRectangle:color:borderWidth:borderColor: 2018659252: a(n) BalloonCanvas 0xbfc88010 M BalloonCanvas>fillRectangle:fillStyle: 2018659252: a(n) BalloonCanvas 0xbfc88030 M FormCanvas>balloonFillRectangle:fillStyle: 2018611404: a(n) FormCanvas 0xbfc88054 M FormCanvas>fillRectangle:fillStyle: 2018611404: a(n) FormCanvas 0xbfc88074 M FormCanvas(Canvas)>fillRectangle:fillStyle:borderStyle: 2018611404: a(n) FormCanvas 0xbfc88098 M SystemWindow(Morph)>drawOn: 2014426088: a(n) SystemWindow 0xbfc880b4 M FormCanvas(Canvas)>draw: 2018611404: a(n) FormCanvas 0xbfc880d0 M FormCanvas(Canvas)>drawMorph: 2018611404: a(n) FormCanvas 0xbfc880f0 M [] in SystemWindow(Morph)>fullDrawOn: 2014426088: a(n) SystemWindow 0xbfc8810c M CornerRounder class>roundCornersOf:on:in:displayBlock:borderWidth:corners: 2007442196: a(n) CornerRounder class 0xbfc8813c M FormCanvas>roundCornersOf:in:during: 2018611404: a(n) FormCanvas 0xbfc88160 M FormCanvas(Canvas)>roundCornersOf:during: 2018611404: a(n) FormCanvas 0xbfc88180 M SystemWindow(Morph)>fullDrawOn: 2014426088: a(n) SystemWindow 0xbfc8819c M FormCanvas(Canvas)>fullDraw: 2018611404: a(n) FormCanvas 0xbfc881b8 M FormCanvas(Canvas)>fullDrawMorph: 2018611404: a(n) FormCanvas 0xbfc88208 M [] in WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: a(n) WorldState 0xbfc88240 I Rectangle>allAreasOutsideList:startingAt:do: 2017358104: a(n) Rectangle 0xbfc8826c I Rectangle>allAreasOutsideList:do: 2017358104: a(n) Rectangle 0xbfc882a8 M [] in WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: a(n) WorldState 0xbfc882cc M Array(SequenceableCollection)>do: 2018529764: a(n) Array 0xbfc882fc M WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: a(n) WorldState 0xbfc88334 M [] in WorldState>displayWorld:submorphs: 2001318316: a(n) WorldState 0xbfc8834c M FormCanvas>roundCornersOf:in:during: 2017358448: a(n) FormCanvas 0xbfc88370 M FormCanvas(Canvas)>roundCornersOf:during: 2017358448: a(n) FormCanvas 0xbfc88398 M WorldState>displayWorld:submorphs: 2001318316: a(n) WorldState 0xbfc883c0 I PasteUpMorph>privateOuterDisplayWorld 2001318568: a(n) PasteUpMorph 0xbfc883e0 I PasteUpMorph>displayWorld 2001318568: a(n) PasteUpMorph 0xbfc88404 I [] in WorldState>displayWorldSafely: 2001318316: a(n) WorldState 0xbfc88420 M BlockClosure>on:do: 2018529472: a(n) BlockClosure 0xbfc88440 M BlockClosure>ifError: 2018529472: a(n) BlockClosure 0xbfc88464 I WorldState>displayWorldSafely: 2001318316: a(n) WorldState 0xbfc88480 M PasteUpMorph>displayWorldSafely 2001318568: a(n) PasteUpMorph 0xbfc88498 M PasteUpMorph>install 2001318568: a(n) PasteUpMorph 0xbfc884c0 I AutoStart class>checkForPluginUpdate 2008299932: a(n) AutoStart class 0xbfc884e0 M AutoStart class>startUp: 2008299932: a(n) AutoStart class 0xbfc8850c M [] in SmalltalkImage>send:toClassesNamedIn:with: 2009624740: a(n) SmalltalkImage 0xbfc88534 I OrderedCollection>do: 2009661056: a(n) OrderedCollection 0xbfc8855c I SmalltalkImage>send:toClassesNamedIn:with: 2009624740: a(n) SmalltalkImage 0xbfc88588 I SmalltalkImage>processStartUpList: 2009624740: a(n) SmalltalkImage 0xbfc885b4 I SmalltalkImage>snapshot:andQuit:embedded: 2009624740: a(n) SmalltalkImage 2014606248 s SmalltalkImage>snapshot:andQuit: 2014606132 s TheWorldMainDockingBar>saveAndQuitSqueak 2014606040 s [] in MenuItemMorph>invokeWithEvent: 2014605924 s BlockClosure>ensure: 2014605832 s CursorWithMask(Cursor)>showWhile: 2014605632 s MenuItemMorph>invokeWithEvent: 2014605540 s MenuItemMorph>mouseUp: 2014605448 s MenuItemMorph>handleMouseUp: 2014605316 s MouseButtonEvent>sentTo: 2014605224 s MenuItemMorph(Morph)>handleEvent: 2014605132 s MorphicEventDispatcher>dispatchDefault:with: 2014605040 s MorphicEventDispatcher>dispatchEvent:with: 2014604948 s MenuItemMorph(Morph)>processEvent:using: 2014604856 s MorphicEventDispatcher>dispatchDefault:with: 2014604748 s MorphicEventDispatcher>dispatchEvent:with: 2014604616 s DockingBarMenuMorph(Morph)>processEvent:using: 2014604524 s DockingBarMenuMorph(Morph)>processEvent: 2014604432 s DockingBarMenuMorph(MenuMorph)>handleFocusEvent: 2014604340 s [] in HandMorph>sendFocusEvent:to:clear: 2014604248 s [] in PasteUpMorph>becomeActiveDuring: 2014604068 s BlockClosure>on:do: 2014603976 s PasteUpMorph>becomeActiveDuring: 2014603856 s HandMorph>sendFocusEvent:to:clear: 2014603764 s HandMorph>sendEvent:focus:clear: 2014603672 s HandMorph>sendMouseEvent: 2014603528 s HandMorph>handleEvent: 2014603180 s HandMorph>processEvents 2014603064 s [] in WorldState>doOneCycleNowFor: 2014602972 s Array(SequenceableCollection)>do: 2014602872 s WorldState>handsDo: 2014602780 s WorldState>doOneCycleNowFor: 2014602688 s WorldState>doOneCycleFor: 2014602596 s PasteUpMorph>doOneCycle 2010011832 s [] in Project class>spawnNewProcess 2010011700 s [] in BlockClosure>newProcess
Most recent primitives basicNew copyBits @ @ @ basicNew @ @ basicNew @ @ @ basicNew copyBits @ @ @ basicNew @ copyBits @ @ @ basicNew basicNew: at:put: @ copyBits @ @ @ basicNew @ @ @ basicNew shallowCopy new: @ @ new: at:put: at:put: at:put: at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ @ basicNew@ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ @ @ basicNew @ @ basicNew basicNew: basicNew @ @ basicNew copyBits @ @ basicNew @ @ @ basicNew basicNew: at:put: at:put: @ basicNew copyBits at:put: @ perform:with: @ @ perform:with: @ basicNew basicNew @ @ @ basicNew basicNew basicNew basicNew new: basicNew: basicNew primitiveSetBitBltPlugin: @ @ basicNew @ @ basicNew @ @ basicNew @ primitiveSetBitBltPlugin: @ @ basicNew @ @ basicNew @ @ basicNew @ @ wait at:put: signal primInitializeBuffer: primSetAALevel: primSetOffset: primSetClipRect: primSetEdgeTransform: primSetColorTransform: primSetEdgeTransform: primSetColorTransform: primGetDepth primSetDepth: new: at:put: at:put: basicNew: species stringHash:initialHash: fractionPart truncated fractionPart fractionPart truncated basicNew basicNew new: value: at:put: value: at:put: at:put: value:value: value:value: basicNew: basicNew: at:put: at:put: at:put: at:put: fractionPart truncated basicNew: at:put: at:put: at:put: at:put: fractionPart truncated basicNew: at:put: at:put: at:put: at:put: truncated truncated truncated truncated at:put: perform:with: truncated Aborted gokr@yoda:~/squeak$
On Jun 20, 2010, at 11:47 45PM, Eliot Miranda wrote:
I expect the next few weeks to involve some bug fixing as it is used in a much broader context (no pun intended). Y'all can help by giving me reproducible test cases.
I made the Float/LargeInt and special object array changes, not sure if it 's just my derived images missing more or an actual bug, but...
[|b| 5] value, and [: a | |b| 5 ] value: 1 crashes in both Squeak and Pharo. Compiler evaluate: '[ :a | | t | ] value: 1' crashes the VM in Pharo 1.1, but not in Squeak. It returns 1 rather than nil though, as is expected in Pharo at least.
Cheers, Henry
Hi Henry,
On Mon, Jun 21, 2010 at 10:22 AM, Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
On Jun 20, 2010, at 11:47 45PM, Eliot Miranda wrote:
I expect the next few weeks to involve some bug fixing as it is used in
a much broader context (no pun intended). Y'all can help by giving me reproducible test cases.
I made the Float/LargeInt and special object array changes, not sure if it 's just my derived images missing more or an actual bug, but...
[|b| 5] value, and [: a | |b| 5 ] value: 1 crashes in both Squeak and Pharo.
Crashes my VM too :) Thanks!!
Compiler evaluate: '[ :a | | t | ] value: 1' crashes the VM in Pharo 1.1, but not in Squeak.
This doesn't crash for me. So this is likely a closure compiler issue. Someone might want to compare the closure compiler in Squeak trunk against Pharo and move the updates across. I'll happily review.
It returns 1 rather than nil though, as is expected in Pharo at least.
Cheers, Henry
On 21.06.2010 20:23, Eliot Miranda wrote:
Compiler evaluate: '[ :a | | t | ] value: 1' crashes the VM in Pharo 1.1, but not in Squeak.This doesn't crash for me. So this is likely a closure compiler issue. Someone might want to compare the closure compiler in Squeak trunk against Pharo and move the updates across. I'll happily review.
Mhhhm, think it might have something to do with http://forum.world.st/BUG-a-value-1-td1298622.html#a1298632 (not sure if you read the rest of the thread after initially replying, but long story short, Pharo ended up changing it to return nil).
As the crash only happens with blocks where there are unused block temps and no block arg usage, I thought it may be another instance of the same bug. With the additional line found in attached changed method commented out, Pharo also returns 1 rather than crash.
Cheers, Henry
On 6/20/2010 2:23 PM, Lukas Renggli wrote:
Thank you Eliot.
This is wonderful, it feels like I just got a new laptop :-)
I noticed some problems in the continuation tests of Seaside (WAContinuationTest, WAFlowPlatformTest and WAPartialContinuationTest):
"Computation has been terminated" in MethodContext>>cannotReturn:Is this a known problem? Or is this maybe specific to Pharo on Cog?
It's a Cog bug. GeneratorTest dies with the same symptoms in 4.1.
Cheers, - Andreas
On 20 June 2010 22:53, stephane ducassestephane.ducasse@gmail.com wrote:
This is really an excellent news. I open a lot of new futures! Thanks teleplace, andreas and all the people that helped.
Stef PS: you already answer my questions about platform were the jit cannot work so this is great.
On Jun 20, 2010, at 10:11 PM, Eliot Miranda wrote:
Hi All,
it gives me great pleasure to announce that the Teleplace Cog VMs are now available. Huge thanks to all at Teleplace who have given me the opportunity to build Cog and release it as open source, been willing guinea pigs braving its bugs, and providing indispensable participation in getting Cog to its current state. Huge thanks are also due to the original Back To The Future team whose VMMaker Cog extends to write the VM, and to Peter Deutsch from whom I've taken many ideas.This release contains two VMs. The Stack VM, is a cross-platform interpreter that uses context-to-stack mapping to achieve modest performance gains. The Cog VM is a just-in-time compiler that currently supports only x86 that builds upon the Stack VM to achieve substantial performance improvements. The release is in the form of a Monticello package containing the VMMaker source and a tarball containing the platform sources, the generated sources and a Squeak 4.1 image containing the VMMaker sources. Download both at http://ftp.squeak.org/Cog/VMMaker-oscog.11.mcz http://ftp.squeak.org/Cog/OpenSourceCog.tar.gz
Cog VMs:
The Cog VMs are Squeak/Croquet VMs that run closure Squeak/Croquet/Pharo/Cuis images. The VMs support existing plugin source but will require plugins to be recompiled as the VM_PROXY_MAJOR plugin api has been extended.
This release contains two distinct VMs, the StackInterpreter and the Cogit. The StackInterpreter is a fully-portable plug-in replacement for the current closure Squeak VMs and images. The Stack VM uses context-to-stack mapping and a somewhat improved garbage collector to achieve modest but useful performance gains in the 10% to 15% range. The StackInterpreter is intended to supersede the Squeak VM on platforms where the Cogit cannot be used. The Cogit extends the StackInterpreter with a just-in-time compiler that uses aggressive inline caching techniques to deliver substantial performance gains in the 3x to 15x range, depending on benchmark. The Cogit currently supports only x86 and the floating-point primitives and parts of the platform support code depend on SSE2. I hope members of the community will attempt to port it, e.g. to ARM, PowerPC and x86-64. The Cogit (excuse the pun) is so named because it is both an interpreter and a JIT, choosing not to generate ma
chine code for large methods, interpreting them instead, the default policy being not to JIT methods with more than 60 literals.
The Cog VM requires a few minor image changes all in image/NecessaryImageChangesForCogToWork.1.cs. The JIT's machine-code SmallInteger primitives insist on a SmallInteger receiver so the primitives in LargePositiveInteger = ~= bitAnd: bitOr: butShift: and bitXor: cannot be used and these methods must be deleted. The Cogit inlines the address of the Character instance table, Smalltalk specialObjectsArray at: 25, into the machine-code at: primitive for faster ByteString>>at: and so the table cannot be rebuilt in SmalltalkImage>>recreateSpecialObjectsArray. The new version preserves the existing table. Both VMs maintain floats in platform order to ease implementation of machine code floating-point primitives, and hence internally are in little-endian order instead of big-endian in current Squeak images. While the VMs convert float order automatically on load they do require special accessing primitives Float>>basicAt:& Float>>basicAt:put: that undo the reversal and an
swer Float contents in big-endian order so that e.g. Float>>hash is unchanged. The methods assume these primitives can fail, allowing the code to be used on current Squeak VMs.
The image/VMMaker-Squeak4.1.image is a Squeak 4.1 image, runnable with the current Squeak VMs, that contains these changes, and can hence also be run with a Cog VM. But beware, once an image has been saved on Cog it cannot be run by an existing Squeak VM, because existing VMs cannot undo the Float order change.
Platform Subsystem:
Most of the platform subsystem is unchanged but there are some important changes that need description. The biggest change is the heartbeat and the clock in platforms/unix/vm/sqUnixHeartbeat.c and platforms/win32/vm/sqWin32Heartbeat.c. The Cog VMs avoid the slow and variable interruptCheckCounter, folding the event check into the stack overflow check on frame build. The heartbeat, typically 500Hz or 1KHz, changes the stackLimit to a value that will always fail. On the next frame building send the VM will enter stack overflow handling that, as a side effect, will also check for events. This is more efficient than the update of interruptCheckCounter and much more regular. If one is running code that executes long-running primitives (e.g. large integer arithmetic) the counter approach will result in too low an interrupt check frequency, and conversely if one is running normal code the interrupt check frequency can be very high.
The heartbeat also maintains a 64-bit microsecond clock, UTC microseconds from 1901, from which the backward-compatible millisecond and second clocks are derived. Primitives exist to answer UTC microseconds and local microseconds. Updating the clock in the heartbeat results in a 1 or 2 millisecond resolution but avoids the cost of accessing the OS time on every prim tie which we've found important for performance at Teleplace. The 64-bit microsecond clocks provide a unified time basis and eliminate wrapping (for the next 54,000 years at least). I hope community images will move to these clocks. It's worked well in VisualWorks.
Another significant change is in the external semaphore table support code. This is now lock-free at the cost of having to specify a maximum number of external semaphores at start-up (default 256). The support code for the lock-free data structures are processor-specific and is currently implemented only for x86 and gcc-compatible compilers; see platforms/Cross/vm/{sqAtomicOps.h,sqMemoryFence.h}.
There is also improved crash reporting code that prints a primitive log and a C backtrace in addition to the Smalltalk backtrace. See platforms/Mac OS/vm/sqMacMain.c, platforms/unix/vm/sqUnixMain.c, platforms/win32/vm/sqWin32Intel.c& platforms/win32/vm/sqWin32Backtrace.c.
Finally there is support for the QVMProfiler, a pc-sampling profiler for profiling at the VM level. See platforms/unix/vm/sqUnixVMProfile.c and platforms/win32/vm/sqWin32VMProfile.c. The profiler itself is in the VMMaker image described below in Qwaq-VMProfiling.
There are also changes to do with Teleplace-specific extensions to the HostWindowPlugin but these are not essential to Cog.
VMMaker and Slang:
The image/VMMaker-Squeak4.1.image Squeak 4.1 image contains the complete Cog VMMaker with necessary support code for simulation. This image was used to generate the sources in the src and stacksrc directories.
Cog's VMMaker is substantially revised and extended from the current VMMaker. It supports multiple classes, not just Interpreter and superclasses, because both context-to-stack mapping and the Cogit are too complex to write monolithically. Classes can specify ancilliaryClasses and ancilliaryStructClasses, such as CoInterpreterStackPage, CogMethod and CogAbstractInstruction. The Monticello package version is included in the header of all generated files and constitutes the version stamp for generated code. Code is generated in sorted order so that minor changes in the Smalltalk source produce correspondingly minor changes in the generated code. The gnuification step is built-in to VMMaker. No effort has been made to maintain 64-bit compatibility. Apologies, this was unaffordable.
The VMMaker generates a single source tree used by all platforms. Instead of deciding at generation time whether to use the Interpreter struct the generated code depends on the SQ_USE_GLOBAL_STRUCT define which can be overridden in platform makefiles. All plugins live in src/plugins and platform makefiles along with plugins.int and plugins.ext files in the build subdirectories decide which plugins are built as external or internal. The VM Generation Workspace from Workspace.text workspace contains dots to generate the sources. We no longer use the VMMakerTool since there should be nothing platform-specific in the generated sources (if we add ports to other ISAs all their source can be included and selected as required by the platform makefiles).
Since the Cogit generates x86 machine code simulation is much more complex. There is a support plugin, platforms/Cross/plugins/BochsIA32Plugin that depends on a large simulation of the x86 family implemented in C++ (see processors/IA32/bochs) and on Alien. I use the simulator frequently (but note that I haven't had time to build a working version for Squeak 4.1). I have tested Cog simulation in this image, running on the image/VMMaker-Squeak4.1.image itself. The VM Simulation Workspace in the VMMaker image contains an example doit that starts the simulator. Be patient, even on a fast machine unhibernating the Squeak display background image takes nearly a minute. Native fonts do not (yet) simulate correctly, but the system runs. But note that I have only attempted to build and run the simulator on Mac OS X. I expect Bochs can be built on linux and win32 but I have not tried. By the way, I've not described how to run the Bochs simulator on the current Squeak VM.
That's because the plugin depends on the heartbeat to break out of simulation occasionally via a new interpreterProxy entry point setInterruptCheckChain. As this isn't supported by the current Squeak VMs the plugin would require modification. So to simulate first build either of the Cog VMs and then run the simulation with it.
There are a number of unpublished changes to the base other than those in NecessaryImageChangesForCogToWork.1.cs. This is partly laziness on my part, partly avoiding publishing things in advance of Cog. These changes are better motivated once Cog is in use. There are changes to the "translated primitives" (see implementors of translatedPrimitives) which replace messages with method tags for generation directives. The Cog VMMaker uses Object>>perform:with:with:with:with:& Object>>perform:with:with:with:with:with: during simulation, and Collection>>#fold:& SquenceableCollection>>#copyUpThrough: during generation. Object>>inline: and Object var:declareC:, which are mispackaged in Kernel in Squeak 4.1 are obsolete (method tags being used instead) and have been removed. I have changed Integer>>hex and Integer>>hex8 back to their original semantics as of 3.8. Backward compatibility is important and one can easily add new selectors if one wants different functionality.
VMMaker was here first ;)
Tarball:
The top-level directories in the tarball are
src the tree for the Cog generated sources including all plugins stacksrc/vm the directory containing the Stack VM source (plugins can be taken from above) platforms the usual svn platform tree but including Cog specific changes such as the heartbeat processors the tree containing simulation support code, i.e. the bochs C++ x86 simulation library, along with a potential ARM, PowerPC& MIPS simulator, Skeye. image the Cog-prepared Squeak 4.1 VMMaker image scripts some svn scripts to revert unchanged plugins that haven't really changed cygwinbuild the win32 build directory winbuild the old win32 build directory for minnow gcc 2.95. Not entirely obsolete as the cygwin build as yet fails to generate a functional FFIPlugin macbuild the CoreVM.xcodeproj and support build projects for Mac OS X 10.5 or better unixbuild the build directory for linuxBuilding Cog:
Each build directory above contains a HowToBuild file that describes building in more detail. The build directories only contain Cogit makefiles. f you want to build a Stack VM you're on your own but this is very close to the existing Squeak VM build.
Status: The Cogit VM has been our sole VM at Teleplace for nearly a year. We do occasionally find bugs and there are almost certainly areas of functionality that we have not touched (for example I know that co-routining does not yet work). If you find a bug please try and create a reproducible test case and let me know. I can't promise to take a look or fix it but I am motivated to do so and will try my best as time allows. Better still if you find and fix bugs be sure to let me know.
License (MIT): All contributions from Teleplace in this release are Copyright (c) 2010 Teleplace, Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Eliot Miranda June 2010
Wonderful news.
On 2010-06-20, at 1:11 PM, Eliot Miranda wrote:
The Cogit currently supports only x86 and the floating-point primitives and parts of the platform support code depend on SSE2. I hope members of the community will attempt to port it, e.g. to ARM, PowerPC and x86-64.
Now before anyone asks, it's very doubtful you will see Cogit on the iOS series of operating systems (iphone/ipad). I have had detailed discussions with the Apple Security team since their goal is to prevent user level code from doing dynamic code generation.
mmap for example won't return a page of memory that is executable.
Let's say the probability of getting Apple to change their minds on this is zero.
However I'll look into the StackInterpreter for the Macintosh 5.x VM and the iOS flavour, mind if anyone wants to do that chore early then they should ping me.
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
For the binary-challenged, I am sure some kind soul will post compiled versions somewhere...!
(I ALWAYS struggle with build.bat, missing files, environment variables, and the like...)
Take care,
Rob
On Sun, Jun 20, 2010 at 5:37 PM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:
Wonderful news.
On 2010-06-20, at 1:11 PM, Eliot Miranda wrote:
The Cogit currently supports only x86 and the floating-point primitives and parts of the platform support code depend on SSE2. I hope members of the community will attempt to port it, e.g. to ARM, PowerPC and x86-64.
Now before anyone asks, it's very doubtful you will see Cogit on the iOS series of operating systems (iphone/ipad). I have had detailed discussions with the Apple Security team since their goal is to prevent user level code from doing dynamic code generation.
mmap for example won't return a page of memory that is executable.
Let's say the probability of getting Apple to change their minds on this is zero.
However I'll look into the StackInterpreter for the Macintosh 5.x VM and the iOS flavour, mind if anyone wants to do that chore early then they should ping me.
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 6/20/2010 2:42 PM, Rob Rothwell wrote:
For the binary-challenged, I am sure some kind soul will post compiled versions somewhere...!
For Windows, get yours here:
http://squeakvm.org/win32/experimental/CogSqueak4.1.zip
Cheers, - Andreas
(I ALWAYS struggle with build.bat, missing files, environment variables, and the like...)
Take care,
Rob
On Sun, Jun 20, 2010 at 5:37 PM, John M McIntosh <johnmci@smalltalkconsulting.com mailto:johnmci@smalltalkconsulting.com> wrote:
Wonderful news. On 2010-06-20, at 1:11 PM, Eliot Miranda wrote:The Cogit currently supports only x86 and the floating-point primitives and parts of the platform support code depend on SSE2. I hope members of the community will attempt to port it, e.g. to ARM, PowerPC and x86-64.Now before anyone asks, it's very doubtful you will see Cogit on the iOS series of operating systems (iphone/ipad). I have had detailed discussions with the Apple Security team since their goal is to prevent user level code from doing dynamic code generation. mmap for example won't return a page of memory that is executable. Let's say the probability of getting Apple to change their minds on this is zero. However I'll look into the StackInterpreter for the Macintosh 5.x VM and the iOS flavour, mind if anyone wants to do that chore early then they should ping me. -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com <mailto:johnmci@smalltalkconsulting.com>> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Sun, Jun 20, 2010 at 01:11:38PM -0700, Eliot Miranda wrote:
Hi All,
it gives me great pleasure to announce that the Teleplace Cog VMs are now available. Huge thanks to all at Teleplace who have given me the opportunity to build Cog and release it as open source, been willing guinea pigs braving its bugs, and providing indispensable participation in getting Cog to its current state. Huge thanks are also due to the original Back To The Future team whose VMMaker Cog extends to write the VM, and to Peter Deutsch from whom I've taken many ideas.
Congratulations Eliot! And many thanks to those who supported your work and had the wisdom and foresight to make it publicly available.
Dave
On Sun, 20 Jun 2010, Eliot Miranda wrote:
Hi All,
it gives me great pleasure to announce that the Teleplace Cog VMs are now available. Huge thanks to all at Teleplace who have given me the
This is fantastic, thanks.
<snip>
attempt to port it, e.g. to ARM, PowerPC and x86-64. The Cogit (excuse the pun) is so named because it is both an interpreter and a JIT, choosing not to generate machine code for large methods, interpreting them instead, the default policy being not to JIT methods with more than 60 literals.
I think it would be better to use an adaptive policy later. Something like: all methods will be inlined if they are evaluated enough times. Say a method with 10 literals will be inlined if it's evaluated 100 times. A method with 100 literals will need 10000 runs, etc. (note: i just made up the numbers).
Levente
Hi Eliot,
Eliot Miranda wrote:
Hi All,
it gives me great pleasure to announce that the Teleplace Cog VMs are now available. Huge thanks to all at Teleplace who have given me the opportunity to build Cog and release it as open source, been willing guinea pigs braving its bugs, and providing indispensable participation in getting Cog to its current state. Huge thanks are also due to the original Back To The Future team whose VMMaker Cog extends to write the VM, and to Peter Deutsch from whom I've taken many ideas.
...
This is wonderful news! Thank you, Andreas, and all the people at Teleplace who made this possible!
I tried to run Cuis on the Windows VM Andreas did, and I'm having trouble. I did as follows:
1) Start Cuis 2.4 with the Closure VM 2) Install the attached changeset (made after your post and the tweaks 3) Exit saving the image 4) Start it with the Cog VM
When starting, it does an invalid memory access, and terminates without any error message or log. I guess I'd need to setup a VM building and debugging environment, etc, and learn quite a bit to fix this myself. I guess it would take you minutes to spot this, compared with the days I'd need to spend... I'd very much appreciate your help.
Thank you.
Cheers, Juan Vuletich
On 6/21/2010 11:29 AM, Juan Vuletich wrote:
When starting, it does an invalid memory access, and terminates without any error message or log. I guess I'd need to setup a VM building and debugging environment, etc, and learn quite a bit to fix this myself. I guess it would take you minutes to spot this, compared with the days I'd need to spend... I'd very much appreciate your help.
I've seen that before :-) Cog requires LargeNegativeInteger to be compact at 5 (previously PseudoContext). After installing and running the attached code in addition to the other changes you're good to go.
Enjoy! - Andreas
Hi Andreas,
Andreas Raab wrote:
On 6/21/2010 11:29 AM, Juan Vuletich wrote:
When starting, it does an invalid memory access, and terminates without any error message or log. I guess I'd need to setup a VM building and debugging environment, etc, and learn quite a bit to fix this myself. I guess it would take you minutes to spot this, compared with the days I'd need to spend... I'd very much appreciate your help.
I've seen that before :-) Cog requires LargeNegativeInteger to be compact at 5 (previously PseudoContext). After installing and running the attached code in addition to the other changes you're good to go.
Enjoy!
- Andreas
Yes. I yesterday downloaded XCode and built the Mac VM, only to find that it throws a clear error (LargeNegativeInteger is not compact at 5, can't continue) to the console. I told this to Eliot, but forgot to say it in the lists. I apologize. Anyway, for some reason, the win vm you posted, instead of giving the error and exiting cleanly, it does an invalid access and is terminated. Maybe you want to check that.
BTW, most console messages (i.e. stdout) will be missed in these days of graphical shells. An OS dialog would be better.
Thank Eliot, you and Teleplace for this great gift! This is a major milestone in the history of Squeak.
Cheers, Juan Vuletich
On 20.06.2010 22:11, Eliot Miranda wrote:
While the VMs convert float order automatically on load they do require special accessing primitives Float>>basicAt: & Float>>basicAt:put: that undo the reversal and answer Float contents in big-endian order so that e.g. Float>>hash is unchanged. The methods assume these primitives can fail, allowing the code to be used on current Squeak VMs.
Should also note, Float divisions by zero now return + / - Infinity rather than raising ZeroDivide errors. 15.0 / 0 Infinity -15.0 / 0.0 -Infinity
Cheers, Henry
On Mon, Jun 21, 2010 at 5:16 PM, Henrik Sperre Johansen < henrik.s.johansen@veloxit.no> wrote:
On 20.06.2010 22:11, Eliot Miranda wrote:
While the VMs convert float order automatically on load they do require special accessing primitives Float>>basicAt: & Float>>basicAt:put: that undo the reversal and answer Float contents in big-endian order so that e.g. Float>>hash is unchanged. The methods assume these primitives can fail, allowing the code to be used on current Squeak VMs.
Should also note, Float divisions by zero now return + / - Infinity
rather than raising ZeroDivide errors. 15.0 / 0 Infinity -15.0 / 0.0 -Infinity
which is clearly a bug in Cog. But I'd like to provide a flag/image-header-bit to allow one to specify either behaviour. i.e. fail float primitives that return NaNs or Infs, or return the relevant IEEE Inf/NaN. Andreas and I have just discussed this and he points out that while under ieee Inf and non-NaN results are bit-identical across platforms, NaNs are not. So for Croquet one really needs the code generator to arrange that float primitives that do return NaNs normalise those NaNs to a small set (e.g. a pair of a single +ve NaN & a single -ve NaN).
cheers, Eliot
Cheers, Henry
Morning all, I've pushed a number of changes into the iOS platform tree to enable you to build a Macintosh Cocoa V5 Cog VM. Well at least one that runs a few million byte codes before crashing. This also requires changes to the Cog branch, but that's part of the re-integration process.
I have also built it as a Stack VM for the iPhone, that runs many more million bytecodes before tossing walkbacks on an unaltered image. Just a bit of image tinkering I think is needed there, plus a change to let complex events flow up out of the VM into the image, but again part of the re-integration process.
On 2010-06-20, at 1:11 PM, Eliot Miranda wrote:
Hi All,
it gives me great pleasure to announce that the Teleplace Cog VMs are now available. ... Eliot Miranda June 2010
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Awesome! Thanks :)
- Bert -
On 08.07.2010, at 03:49, John M McIntosh wrote:
Morning all, I've pushed a number of changes into the iOS platform tree to enable you to build a Macintosh Cocoa V5 Cog VM. Well at least one that runs a few million byte codes before crashing. This also requires changes to the Cog branch, but that's part of the re-integration process.
I have also built it as a Stack VM for the iPhone, that runs many more million bytecodes before tossing walkbacks on an unaltered image. Just a bit of image tinkering I think is needed there, plus a change to let complex events flow up out of the VM into the image, but again part of the re-integration process.
On 2010-06-20, at 1:11 PM, Eliot Miranda wrote:
Hi All,
it gives me great pleasure to announce that the Teleplace Cog VMs are now available. ... Eliot Miranda June 2010
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
David T. Lewis -
Eliot Miranda -
Göran Krampe -
Henrik Johansen -
Henrik Sperre Johansen
-
John M McIntosh -
Juan Vuletich -
Levente Uzonyi -
Lukas Renggli -
Michael Haupt -
Rob Rothwell -
stephane ducasse