Vm-dev October 2010

vm-dev@lists.squeakfoundation.org

27 participants
60 discussions

ffi-test-main.c fails on FreeBSD
by Gary Dunn 12 Aug '16

12 Aug '16

In conjunction with getting Open Cobalt running on FreeBSD I have been looking into the problems with SqueakFFIPrims on FreeBSD and have reached a point that is beyond my understanding. I am not sure if the fix should come from the VM side or the FreeBSD port maintainer. I needed to get source code back into the ports tree so I did a make in /usr/ports/lang/squeak. I already had the 3.9 tarball, so that just repopulated the source and did the initial build. In the "files" folder I found patch files typical for a FreeBSD port. These patch source files from a generic tarball to work with FreeBSD. The one of interest was patch-platforms__unix__plugins__SqueakFFIPrims__ffi-config which contains ----x-----x----- --- platforms/unix/plugins/SqueakFFIPrims/ffi-config.org Wed Apr 26 20:27:53 2006 +++ platforms/unix/plugins/SqueakFFIPrims/ffi-config Wed Apr 26 20:29:00 2006 @@ -39,6 +39,7 @@ case ${abi} in linux) abi=sysv;; + freebsd*) abi=sysv;; darwin*) abi=darwin;; *) abi=libffi; lib="-lffi";; esac -----x-----x----- I then had the folder work/Squeak-3.9-7/platforms/unix/plugins/SqueakFFIPrims In it is a file 00README which explains how to test FFI. It says to run ffi-test-config but I have no such file. It says to type "make" to build a test suite but the build failed. It says to try with make CPU=any ABI=libffi LIB=-lffi which also failed. I traced the problem to the gcc search paths for includes and libraries -- turns out FreeBSD only searches /usr/include and /usr/lib when the required files are in /usr/local/include and /usr/local/lib. After some fiddling I finally had a "main" to test. It failed: ffi-test-main.c failed at line 361. Here is a bit from that file, ending with line 361: ffiInitialize(); for (ul= 0; ul < 15; ++ul) ffiPushSingleFloat(fa[ul]); GO(FFITypeSingleFloat, many); f= ffiReturnFloatValue(); ffiCleanup(); CHECK(f - ff < FLT_EPSILON); I worked out the CHECK macro but could not find what FLT_EPSILON is. At that point I decided to stop and come to you for help. Where do I go from here? -- Gary Dunn, Honolulu osp(a)aloha.com http://openslate.net/ http://e9erust.blogspot.com/ Sent from Slate001

5 8

Profiling and delay accuracy
by Andreas Raab 06 Aug '11

06 Aug '11

Hi Folks - For a long time now I had this feeling that MessageTally reports pretty bogus results in many situations without being able to precisely track down why this would be the case. Today I was looking at primitiveResponse() and, much to my surprise, noticed that the checkForInterrupts() that used to be there for years is gone (see Squeak3.6 for example which still has it). The sole reason for this check was to get both high delay accuracy and good profiling behavior. Consider this example: fc := FormCanvas on: Display. MessageTally spyOn:[ 1 to: 100 do:[:i| fc fillColor: Color white. fc printString. ]. ]. Using 3.6 this will be measured correctly as: **Tree** 87.5% {243ms} FormCanvas>>fillColor: |87.5% {243ms} GrafPort>>fillRect:offset: | 87.5% {243ms} GrafPort>>copyBits 12.5% {35ms} FormCanvas(Object)>>printString 12.5% {35ms} FormCanvas(Object)>>printStringLimitedTo: whereas the 3.10 reports it as **Tree** 99.6% {670ms} FormCanvas(Object)>>printString 94.9% {639ms} primitives 4.6% {31ms} FormCanvas(Object)>>printStringLimitedTo: I think you can see the problem and just imagine what this does to any cumulative results. I also wonder what that change does to platforms that don't have high-resolution asynchronous timers. This used to be the one place where we would catch timer changes at high resolution and unless the platform forces high resolution timer interrupts asynchronously (by resetting the interrupt counter) we must be loosing a lot in terms of delay accuracy. (it just so happens that the Windows VM *does* do asynchronous timer interrupts so I never noticed this but I'm very curious about the difference on Linux which typically still has pretty bad timer granularity). Any opinions? My feeling is that the timer check should go back in for all of the above reasons. At the very least a quickCheckForInterrupt() is required but I actually think putting the full check back in is worth it. Cheers, - Andreas

3 3

4.0.3.2196 for Unix
by Ian Piumarta 08 May '11

08 May '11

Folks, Source and binaries for Linux/i386, Darwin/i386 & Darwin/PPC now available. (Solaris, NetBSD and FreeBSD still at 3.11.3 until I get my kvm working again.) http://squeakvm.org/unix Enjoy! Ian Major changes since 3.11.3.2135: Generated sources rebuilt from VMMaker-dtl.169. Re-enabled MIDI support via ALSA on Linux. Broken locales should no longer cause line ends to go missing during copy and paste. Add support for "platform source version" primitive. Remove debugging beep on first clipboard copy under X11. Allow fully-qualified pathnames when loading modules. Bundle FreetypePlugin with source and binary releases. Various fixes for 64-bit cleanliness (many thanks to Dave Lewis). Add microsecond clock support. Fix launching from a menu under KDE. Fix --CFLAGS option in configure script. Serial plugin invalidates cached port names on close. Better handling of symlinks when looking for absolute path to VM binary.

5 12

Joys of Squeak-dev image, VM Compiling on MacIntel and Spoon remote OtherBrowsing
by Ken G. Brown 16 Nov '10

16 Nov '10

MacPro OS X 10.4.9 Xcode 2.4.1 Squeak-dev-114-2, VMMaker 2.8b6.1, Squeak 3.8.15beta6U.app, and version 1657 of svn MacOS VM sources, and Spoon v2a12. Downloaded http://www.squeakvm.org/cgi-bin/viewcvs.cgi/ trunk version 1657 for MacOS Ran squeak-dev-beta-114-2.image on Squeak 3.8.15beta6U.app Loaded VMMaker 3.8b6.1 from dev image Universes. Generated vm sources by following instructions in <http://www.squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/Mac%20OS/vm/Doc…> Fought with Xcode wanting to use MacOSX10.3.9.sdk for ppc which was giving an error which was known and documented in the Readme. Finally figured out what Xcode wanted so built universal app just using 10.4.9 sdk. Couple issues: Exupery references remain in sqnamedPrims.h and sqPlatformSpecific.h from svn version 1657, I just commented them out. Notes said: Info-NPSqueak__Upgraded_.plist was to be found in the Developer directory. I could not find it so scammed a info.plist out of John's Squeak 3.8.15beta6U.app vm. Not sure what impact this has. And much, much diddling about figuring out various things... Finally got a build. It's a lot smaller (3.9MB) than John McIntosh's Squeak 3.8.15beta6U.app (8.1MB), and it looks like it is a PowerPC one but at least it runs. I'll look into the Xcode build process some more. Then: Replaced interp.c with Craig's interp.c for Spoon, rebuilt and got a VM with Spoon client stuff. Downloaded Spoon release 2a12. Moved a copy of Flow plugin from within Craig's naiad.app package into a plugins subdirectory where the new spoon client compatible MacIntel universal VM was run from. Followed Craig's Spoon instructions for loading niaid.st and niaid.pr into the 3.10 image (Squeak-dev-114-2) running on the new VM. Did the run spoon.app thing from Spoon.dmg (version 2a12), needs to be done twice if Safari is not running. Got Spoon processor running. Followed instructions again in the Spoon client and lo! Got OtherBrowser browsing the Spoon memory running on processor. Yay Craig! Who do i get to sign my certificate? :) Ken

4 7

Problem changing primitiveBitOr or primitiveBitAnd
by Mariano Martinez Peck 07 Nov '10

07 Nov '10

Hi, I want to change #primitiveBitOr or #primitiveBitAnd and in both cases, I compile the VM, I run an image, and the image cannot even start and CPU 100% :( I have a loop somewhere. This is the current implementation of #primitiveBitOr for example: primitiveBitOr | integerReceiver integerArgument | integerArgument := self popPos32BitInteger. integerReceiver := self popPos32BitInteger. successFlag ifTrue: [self push: (self positive32BitIntegerFor: (integerReceiver bitOr: integerArgument))] ifFalse: [self unPop: 2] I NEED to have the receiver oop and the argument oop. So, I've change it to: primitiveBitOr | integerReceiver integerArgument arg rcvr | arg := self popStack. integerArgument := self positive32BitValueOf: arg. rcvr := self popStack. integerReceiver := self positive32BitValueOf: rcvr. successFlag ifTrue: [ self push: (self positive32BitIntegerFor: (integerReceiver bitOr: integerArgument))] ifFalse: [self unPop: 2] And then to: primitiveBitOr | integerReceiver integerArgument arg rcvr | arg := self stackValue: 0. integerArgument := self positive32BitValueOf: arg. rcvr := self stackValue: 1. integerReceiver := self positive32BitValueOf: rcvr. successFlag ifTrue: [ self push: (self positive32BitIntegerFor: (integerReceiver bitOr: integerArgument))] ifFalse: [self unPop: 2] But in both cases, while trying to start an image, I have cpu 100% Of course, the same happens if I do this in #primitiveBitAnd Any ideas what can be happening? because I tried to understand but nothing :( Thanks in advance Mariano

7 8

SmartSyntaxPlugins simulation whitewash
by Eliot Miranda 07 Nov '10

07 Nov '10

Hi All, I just read Anthony Hallinan's most informative comment to SmartSyntaxPlugin class>>simulatorClass which says that "By default SmartSyntaxInterpreterPlugin answers nil because methods in these plugins are intended to be embedded in code that pushes and pops from the stack and therefore cannot be run independently. This wrapper code is generated when translated to C. But, unfortunately, this code is missing during simulation. There was an attempt to simulate this, but only the prologue code (getting arg from the stack) is simulated (see simulatePrologInContext:). The epologue code (popping args and pushing result) is not. So I am making this nil until this can be fixed. Also, beware that primitive methods that take no args exactly match their primitive name (faking out InterpreterSimulator>>callExternalPrimitive:). They should only be called from within wrapper code that simulates the prologue and epilogue. Primitive method that take args don't have this accidental matching problem since their names contain colons while their primitive names do not. - ajh 8/21/2002" Strikes me that what needs to be done is to throw away the tricky implementation of Object>>#primitive:parameters:receiver:, replacing it by a simple direct implementation, and putting a wrapper around each SmartSyntaxPlugin primitive as its installed whose job it is to check for success and if so, cut back the stack and convert the result. Anyone interested who's not also hugely busy? If so, focus on making LargeIntegersPlugin work using 22 factorial printString as a test case. best Eliot

3 2

Tracing special messages [WAS] Re: [Vm-dev] Re: normalSend, specialObjectsArray and VM
by Mariano Martinez Peck 07 Nov '10

07 Nov '10

Hi. So....if I want to intercept ALL message sends....going to #normalSend is not enough since I have #class, #==, Float>>#+ etc that are executed directly like bytecodes. So...my questions are now: 1) Those special selectors are those that are in "Smalltalk specialSelectors" ? are there more? all from there are special? 2) All those "Smalltalk specialSelectors" have their associated bytecode primitive in Interpreter?? If true, then I should modify all bytecodePrim* in Interpreter. I am right? If I do that, that's all ? I am intercepting everything? Thanks a lot in advance, Mariano On Sun, Oct 3, 2010 at 11:09 PM, Craig Latta <craig(a)netjam.org> wrote: > > > > Craig Latta has done all this work, talk to him. > > Sure, I'd be happy to discuss it. > > > -C > > -- > Craig Latta > www.netjam.org > + 31 020 894 6247 > + 1 415 287 3547 > > > >

3 8

Getting stable Cog build on Ubuntu linux
by Igor Stasenko 07 Nov '10

07 Nov '10

Hello, few weeks ago i reported that i experienced Cog VM crashes soon after starting it. I though that it could be related to pthread library, listed twice in GCC options.. I was managed to build a stable VM but now i found that problem is not in that! The VM, which i was built were using debugging-enabled, with all bells&whistles config.. But once i tried a 'release' config, the VM is crashing: ../../platforms/unix/config/configure --without-vm-display-fbdev --without-npsqueak -prefix=/home/sig/cogvm/ CFLAGS="-g -O2 -msse2 -D_GNU_SOURCE -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0" Then i tried to gradually change various options and foudn that this one produces stable VM: ../../platforms/unix/config/configure --without-vm-display-fbdev --without-npsqueak -prefix=/home/sig/cogvm/ CFLAGS="-g -O1 -msse2 -D_GNU_SOURCE -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0" (the difference is just an optimization option O2 vs O1 ) It seems like a compiler related issue.. Any ideas what wrong with O2? 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. -- Best regards, Igor Stasenko AKA sig.

2 2

VM Maker: VMMaker-dtl.197.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 25 Oct '10

25 Oct '10

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.197.mcz ==================== Summary ==================== Name: VMMaker-dtl.197 Author: dtl Time: 24 October 2010, 9:21:53 am UUID: b1f8aaa9-c670-46eb-88ef-54b22da91c78 Ancestors: VMMaker-dtl.196 VMMaker 4.3.11 Adopt TAssignmentNode>>emitCCodeOn:level:generator: from oscog for proper code generation of ifTrue:ifFalse assigned to a variable. Reference Mantis 7455: VM overwrites extraVmMemory value with junk on 64 bit image. For a 64-bit image, the file header may include large machine addresses and thus is stored as 16 words of size 64 (not 32). Change #writeImageFileIO: to produce header size 128 for 64-bit images. The SystemTracer already handles this properly, but the VM proper has had this bug for some time. It causes no functional problems but could become an issue as StackInterpreter makes use of additional header fields.

1 0

VM Maker: VMMaker-dtl.196.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 25 Oct '10

25 Oct '10

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.196.mcz ==================== Summary ==================== Name: VMMaker-dtl.196 Author: dtl Time: 24 October 2010, 8:33:12 am UUID: fe172c7d-58b6-4dd1-9251-6dae5a6ada99 Ancestors: VMMaker-dtl.195 VMMaker 4.3.10 Add missing CCodeGenerator>>newCascadeTempFor: from oscog. Remove some crtab: formatting changes introduced in TMethod from oscog. This reduces cosmetic differences in generated code to simplify comparison of code generation versus earlier VMMaker versions. Generated code is equivalent now, although order of assignment of generated temp var names and goto targets is different. The oscog implementation is better in this respect, so retain the oscog version.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev October 2010