Vm-dev April 2009

vm-dev@lists.squeakfoundation.org

22 participants
37 discussions

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

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

Loading VMMaker into latest Pharo
by Igor Stasenko 01 May '09

01 May '09

There are multiple issues, when loading VMMaker into closure-aware image (10292). two #needsToRegenerateInterpreterFile methods storing into block args. Fix is easy and quick. But what to do with this?? Compiler reporting 'stack including temps is too deep'. GeniePlugin>>primSameClassAbsoluteStrokeDistanceMyPoints: myPointsOop otherPoints: otherPointsOop myVectors: myVectorsOop otherVectors: otherVectorsOop mySquaredLengths: mySquaredLengthsOop otherSquaredLengths: otherSquaredLengthsOop myAngles: myAnglesOop otherAngles: otherAnglesOop maxSizeAndReferenceFlag: maxSizeAndRefFlag rowBase: rowBaseOop rowInsertRemove: rowInsertRemoveOop rowInsertRemoveCount: rowInsertRemoveCountOop (yes, this is a method's message pattern) :) i stopped trying to load VMMaker at this method. It would be nice to have VMMaker loaded in image+closures running under VM+closures :) -- Best regards, Igor Stasenko AKA sig.

4 8

How to use Croquet VMMaker
by Matthew Fulmer 29 Apr '09

29 Apr '09

Hi. In anticipation of working on HydraVM, I am trying to test as close a configuration as possible to HydraVM without being hydra. That is, load the nearest ancestor VMMaker and C sources to hydra, and try to make a working VM. This should help ensure that there are no "normal" bugs once I switch to Hydra, only hydra bugs. So, I did that: Here is my setup: - Fedora core 7 on x86 processor - Release 3.9 image/VM from squeak.org - Load FFI from SqueakMap - Load VMMaker-ar.70 from http://jabberwocky.croquetproject.org:8889/Homebase/ - Checkout http://squeakvm.org/svn/squeak/trunk revision 1796 (The nearest ancestor of HydraVM) I pointed VMMaker at the platforms directory in the checkout, and told it to build source in platforms/unix/src. I selected all plugins to be external, but moved FilePlugin and SocketPlugin to be internal. Then I did mkdir unixbuild cd unixbuild ../platforms/unix/config/configure make make fails linking gnu-interp.o: /bin/sh /home/matthewf/squeak/vm/hydravm-trunk-base/unixbuild/libtool --mode=link gcc -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -export-dynamic -R/usr/local/lib -o squeak vm/vm.a FilePlugin/FilePlugin.a SocketPlugin/SocketPlugin.a disabledPlugins.o version.o -lutil -ldl -lm -lnsl vm/vm.a gcc -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -o squeak disabledPlugins.o version.o -Wl,--export-dynamic vm/vm.a FilePlugin/FilePlugin.a SocketPlugin/SocketPlugin.a -lutil -ldl -lm -lnsl vm/vm.a -Wl,--rpath -Wl,/usr/local/lib vm/vm.a(gnu-interp.o): In function `primitiveGetWindowLabel': /home/matthewf/squeak/vm/hydravm-trunk-base/unixbuild/vm/gnu-interp.c:15141: undefined reference to `ioGetWindowLabel' vm/vm.a(gnu-interp.o): In function `primitiveSetWindowLabel': /home/matthewf/squeak/vm/hydravm-trunk-base/unixbuild/vm/gnu-interp.c:18770: undefined reference to `ioSetWindowLabelOfSize' collect2: ld returned 1 exit status Building this VM worked when using the latest VMMaker from SqueakMap (VMMaker-tpr.58), everything else the same. Is there something else I need to do in order to build using the Croquet VMMaker? I want to use it specifically, since the Hydra VMMaker is derived from it. The dev notes on Hydra are at http://squeakvm.org/~sig/hydravm/devnotes.html -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

5 9

Sound is working on 64-bit Linux now
by David T. Lewis 28 Apr '09

28 Apr '09

See http://bugs.squeak.org/view.php?id=7103 With these changes, sound works on 64-bit Linux ALSA and OSS for both 32-bit and 64-bit images. There are changes to Cross/plugins/SoundPlugin/SoundPlugin.h so some updates will be required for win32 and Mac OS (minor changes to pass pointers properly). Dave

3 8

Re: [vm-dev] How to run InterpreterSimulator?
by askoh 24 Apr '09

24 Apr '09

Thanks. My faith is restored. Aik-Siong Koh -- View this message in context: http://www.nabble.com/How-to-run-InterpreterSimulator--tp23151998p23203956.… Sent from the Squeak vm-dev mailing list archive at Nabble.com.

2 1

SerialPlugin support for named devices (ttyUSB0)
by David T. Lewis 24 Apr '09

24 Apr '09

S??verin Lemaignan has implemented support for named serial devices (e.g. '/dev/ttyUSB0'). My understanding is that this is an important feature for supporting SqueakBots for children in classroom settings, so it would be nice if we can incorporate this in the main VM distributions. The Mantis bug report and S??verin's code are at http://bugs.squeak.org/view.php?id=7266. I added an update for SerialPlugin that allows the new primitives to be properly generated from VMMaker, and also changes the method signatures in SerialPlugin.h to resolve 64-bit issues, permitting SerialPlugin to work on 64-bit Linux. Because of the changes to SerialPlugin.h, support code changes will be required for Windows an Mac as well as Unix. For this reason (assuming that we agree that the changes are a good thing), we will need to schedule a time at which the platforms and VMMaker changes can be updated within some reasonable time window ("reasonable" meaning over a period days or weeks as opposed to months). Ian is away right now, so we should think about doing this at a later date, perhaps next month if schedules permit. I should mention also that I think we have a number of issues like this that need coordinated updates (notably from my point of view the 64-bit FFI updates), and it would be good to do an easy one such as the SerialPlugin update in order to exercise the process. Dave

1 0

Re: [vm-dev] How to run InterpreterSimulator?
by David T. Lewis 23 Apr '09

23 Apr '09

On Thu, Apr 23, 2009 at 10:25:22AM -0300, Jecel Assumpcao Jr wrote: > > David T. Lewis wrote: > > > That said, I don't think anyone is actively working on it right now, > > at least not from the point of view of making the simulator work > > across a range of image versions and VM versions. > > It seems that Aik-Siong Koh is trying to load a 3.10.2 image into a > simulator running inside the same 3.10.2 image and so doesn't care about > other combinations. Usually, the more recent the simulated image the > more complicated it is to make things work since it demands more > features from the simulated VM than an older image would. > > Here are four bug fixes that are probably relevant for getting the > simulator to understand 3.10.2: > > http://bugs.squeak.org/view.php?id=6555 > > Previously I had just tried loading them all, but that didn't work and a > quick look shows that they are not compatible with each other. > > My plan is to attack this problem (probably over the weekend) and > develop a script that will load all needed components and fixes so that > the simulator running inside Squeak 3.10.2 will work with the most > recent image possible (I will aim for 3.10.2 but might have to settle > for something older than that - the script will have comments on which > image to get). Jecel, Thanks, that's great to hear! I see also that Aik-Siong Koh has opened a Mantis entry "0007341: How to run InterpreterSimulator?" at http://bugs.squeak.org/view.php?id=7341. You can probably treat this is a parent issue. Dave

1 0

How to run InterpreterSimulator?
by askoh 23 Apr '09

23 Apr '09

I downloaded Squeak3.10.2-7179-win32.zip Launched a fresh image. Clicked Package Universe Browser. Clicked Update list from network. Select/System/FFI version 3.9.1 Clicked Select package. Repeat for FFI examples version 3.9 FFI Tests version 3.9 Clicked Install selections. Visit http://www.squeaksource.com/VMMaker.html Download http://www.squeaksource.com/VMMaker/VMMaker-dtl.119.mcz In Squeak, Click/open/Monticello Browser/ Locate VMMaker-dtl.119.mcz and load it. In Squeak, open browser on InterpreterSimulation, read comments Highlight and doit. (InterpreterSimulator new openOn: Smalltalk imageName) test And I get an exception. What am I doing wrong? All the best, Aik-Siong Koh -- View this message in context: http://www.nabble.com/How-to-run-InterpreterSimulator--tp23151998p23151998.… Sent from the Squeak vm-dev mailing list archive at Nabble.com.

3 3

Re: [Vm-dev] (fwd) Re: 6502
by David T. Lewis 23 Apr '09

23 Apr '09

On Wed, Apr 22, 2009 at 01:36:25PM -0300, Jecel Assumpcao Jr wrote: > > Here is a discussion that I started on another list, but which we agreed > that it would be better to have it here. > > I should mention that I do see that version numbers are too linear to > properly represent development that often branches in complex ways. I > would personally prefer to use image version numbers as we do now (to > indicate radical changes) and have some special in-image object to > represent the features that are needed. It could be a well known array > of symbols (or strings) like #(exceptions weakPointers exupery > utf8input) so the VM could check that it can fully work with that image. > But I think something like this is even less likely to be accepted than > incrementing 6502... > I suggest that we do the following to support future image format changes: Treat the imageFormatVersion value as a bit map of size 32, derived from the 32-bit integer value saved in the image header. Bits in the bit map represent image format requirements, e.g. if image sets bit 15 to indicate "needs object header inversion", then VM can check bit 15 and decide whether it can support this (whimsical) requirement. As you suggest, a special in-image object should interpret the bit map to represent the features and document their intent. Given current usage (6502, 6502, 68000, and 68002) we have 10 bits currently in use, and 22 available for future use. Reserve the high order bit for future extention in case 32 bits is not enough. This leaves 21 bits for future image format changes. Make one change right now: The imageFormatVersion number for a 64-bit image with closure bytecode support should be changed from 68002 to 68008. This means that bit number 4 (one-base indexing) means "image requires closure bytecode support" for both 32-bit and 64-bit image formats. The change only effects people running 64-bit images with closures (I am quite confident that this is a small number of people). Policy: Anyone making a significant image format change that they wish to be supported by standard VMs can register a bit in the imageFormatVersion bit map. When we run out of bits, allocate a second 32 bit value, set the extension bit, and carry on. If that's not enough, burn the disk packs ;) How the imageFormatVersion value is used and modified: Image responsibilities: - Image is responsible for knowing its imageFormatVersion. - Image is responsible for modifying its imageVersionNumber if new capabilities are required - Image is responsible for informing the VM of any change (note: An image with closure bytecodes does this, albeit indirectly). VM responsibilities: - VM is responsible for reading imageFormatVersion from image header on image load - VM is responsible for determining if it can support the image format and for deciding what to do if it cannot support the image format - VM is responsible for saving the (possibly updated) imageFormatVersion on image save Note: Eliot's implementation for closure support does all of the above. For reference, here are the bits in the imageFormatVersion word that are currently in use (1 means that the bit is used by one of the four current image format numbers): Bit 1 ==> 0 Bit 2 ==> 1 Bit 3 ==> 1 Bit 4 ==> 1 (the "closure bytecodes required" bit) Bit 5 ==> 0 Bit 6 ==> 1 Bit 7 ==> 1 Bit 8 ==> 1 Bit 9 ==> 1 Bit 10 ==> 0 Bit 11 ==> 0 Bit 12 ==> 1 Bit 13 ==> 1 Bit 14 ==> 0 Bit 15 ==> 0 Bit 16 ==> 0 Bit 17 ==> 1 Bit 18 ==> 0 Bit 19 ==> 0 Bit 20 ==> 0 Bit 21 ==> 0 Bit 22 ==> 0 Bit 23 ==> 0 Bit 24 ==> 0 Bit 25 ==> 0 Bit 26 ==> 0 Bit 27 ==> 0 Bit 28 ==> 0 Bit 29 ==> 0 Bit 30 ==> 0 Bit 31 ==> 0 Bit 32 ==> 0 (reserve as extension bit) - Dave > ====forwarded==== > Hi Jecel - > > I think this discussion is probably better done on either Squeak-dev or > VM-dev, so I'll only add one short comment. The current VMs do support > both the pre- and the post-closure format in precisely the way you are > describing. Eliot made it so that an image is being marked as closure > version if the closure creation bytecode is ever executed so that one > may load a pre-closure image, run the conversion script, and save it as > a post-closure version. In the future (i.e., when using the Stack VM) > the pre-closure format will no longer be supported but for the interim > period both are supported. > > Cheers, > - Andreas > > Jecel Assumpcao Jr wrote: > > I'm posting this here since it is a policy issue, but I would be equally > > happy to discuss this in vm-dev or squeak-dev if anyone thinks those > > would be better options. > > > > One interesting tool that we have in Squeak is the image version number. > > This is supposed to allow a VM to check that it is compatible with some > > image before trying to use it. Most images still use the original 6502 > > version, with the 64 bit images having a different number (68000, so it > > seems we have a theme of "important microprocessors in Apple history"). > > > > I think that the policy so far has been to save this tool for something > > really big, so changes to the VM in the past have not resulted in new > > image version numbers. An example would be the introduction of > > exceptions. Certainly the new VMs could fully handle old images - these > > would just never trigger the newly added code. Unfortunately, old VMs > > would not be able to deal with new images. They might seem to for quite > > a while and only if an exception were actually triggered would things > > break down. So casual tests might indicate bidirectional compatibility > > even if specific tests would prove that not to be the case. So keeping > > the old number would lead some people (but not most, who tend to use the > > very latest VMs) into trouble while bumping up the number would make the > > new VMs refuse to load images even though it is perfectly fine for them > > to do so. > > > > A simple solution would be for VMs to look for a list of compatible > > image numbers rather than a single one. The new exception VMs would > > accept either 6502 or 6503 images, for example. This would allow all > > valid combinations to continue to work while preventing new images from > > running on the old VMs where they could break. Of course, one worry is > > that this list might grow to be a significant overhead for future VMs, > > but that is unlikely to happen (specially if numbers are assigned wisely > > so simple ranges could cover most cases). > > > > It seems that the fruits of Eliot's Cog work is being adopted in pieces. > > There are several VMs and images out there using his closure changes, > > and I hope we will next see the Stack Pages, the Jitter, new header and > > the cleaner bytecodes get widely used. This last upgrade will no doubt > > force us to select a new image number, but will all the previous ones > > stick with 6502? > > > > An interesting thread on squeak-dev and vm-dev is about non ASCII input > > from keyboard and clipboard. My own experience from this came late last > > week when I was forced to reinstall all my applications after a hardware > > replacement. So I went to download.squeak.org (nice to have this new > > URL) and got the latest Linux VM for Squeak. This image (I use Celeste > > for my email) seemed to work just fine as long as I was replying in > > English, but pressing the key for ~ got me a debugger. Testing showed > > that any deadkey character caused the same problem. A quick look at the > > release history part of the Unix VM page showed that 3.10-1 had changed > > the keyboard input. So I thought it was silly for me to try to use a 3.9 > > image with a 3.10-4 VM and tested a 3.10.2 image instead. But it has the > > same error - I suppose only the Etoys image has the needed code to deal > > with the new VM events. My opinion is that proper use of the image > > version number could at least have generated a nice warning (no big deal > > for me - I just got a 3.7-7 VM instead and am using that, but what about > > "normal" users?). > > > > I was hoping we could hold off all image changes for one big leap in > > Squeak 5.0 since I have been comparing such a transition to the changes > > Apple has gone through with the Mac and how disruptive this can be. But > > now I feel this battle has been already lost and the current incremental > > path will be the norm. So could we at least agree to use the only tool > > we have, the image version number, to let people know what is supposed > > to work and what isn't? > > > > Many cheers, > > -- Jecel

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev April 2009