Vm-dev November 2005

vm-dev@lists.squeakfoundation.org

15 participants
17 discussions

Plugins and Platforms
by Bert Freudenberg 25 Nov '05

25 Nov '05

Hi folks, when writing a plugin in Slang I encountered two problems wrt platform specifics: 1) convert a squeak pathname to a platform pathname: * my plugin links to a library that expects a platform file path * must convert from Squeak path (char encoding etc.) * sqFilenameFromString() should do this * PROBLEM: this does not work in an external plugin * because it is just a macro pointing to some platform-code function that would have to be linked to the external plugin * PROPOSAL: provide an ioFilenameFromString() function exported from the VM * looked up by plugin via interpreterProxy->ioLoadFunctionFrom ("ioFilenameFromString", "") * could trivially be implemented by using sqFilenameFromString macro? 2) endianness: * I need to know the current platform's endianness * because the linked library provides 8 bit bitmap data in platform order * and I want to adjust the Squeak form from the plugin (set depth to -8 on little-endian machine) * PROBLEM: which function/macro to use? * there seem to be several: - LSB_FIRST used in B3DAcceleratorPlugin.c - MSB_FIRST used in sqWin32Window.c - WORDS_BIGENDIAN defined on Mac OS and Unix - is this the one? thanks, - Bert -

3 2

Cross-platform floating point behavior
by Andreas Raab 22 Nov '05

22 Nov '05

Hi Folks, I had quite a bit of fun with trying to achieve bit-identical floating point behavior across platforms for Croquet. Turns out our claim about "bit identical" behavior is not so bit-identical when it comes to floating point after all. Reading up on IEEE754 and some of the more interesting fpu options like extended internal fpu accuracy or fused multiply-add (all of which are "consistent" with IEEE754 although delivering different results) I have found a wonderful little library (http://www.netlib.org/fdlibm/) which deals very well with these issues. Using it, I have been able to get truly bit-identical results between x87 and PPC and I think it likely that other architectures (Sparc, Arm, Mips) can be made to work with this library as well. Which raises an interesting question: Should we change the VM so that by default we *always* use that library? It would mean replacing our boiler-plate #include<math.h> by an #include<fdlibm.h> and having to link everything (both the VM as well as external plugins if needed) with the library, the cost of which is somewhere in the 60kbytes range. Together with a few platform specific tweaks (like setting the default accuracy on x87 to 53 bits mantissa, or disabling fused-madd on PPC) it *should* make floating point behave perfectly bit-identically across platforms. A word about the runtime efficiency: The overhead seems to be fairly acceptable for the most common uses. Using the primitives, I have been unable to measure noticable differences between the current primitives and the fdlibm primitives *except* for the implementation of sqrt(x) which appears to be significantly faster in hardware. However, both on x87 and PPC it turns out that the results are bit-identical both across the architectures as well as in comparison to fdlibm. And that in turn means we can use the hardware sqrt directly. Note that none of the other implementations give identical results; in particular when it comes to boundary or extreme cases (like huge exponents) the results can *vastly* differ - up to the point that x87 will tell you that sin(1.0e100) is NaN which obviously ridiculous. fdlibm computes this to -0.38 and I have no idea if that's to be considered "correct" but at least we get consistent results across the various platforms. What do you think? It is worth using fdlibm generally instead of -lm? Cheers, - Andreas PS. If somebody has access to Sparc/Mips/Arm I would be interested to see how they behave.

3 2

External Plugin returning too quickly
by Brad Fuller 21 Nov '05

21 Nov '05

The plugin that I'm creating seems to return too quickly. I have a simple test that plays a sine wave and waits 5 seconds (using usleep). The problem is that it stops the sine wave and returns in about a half a second (I hear the sine wave but just a blip. And no errors from the external code.) The code works fine outside of Squeak, but not called from Squeak. The plugin does 2 simple things: * Starts a stream that calls a callback routine (below) * The callback fills a buffer for the sine wave data and then returns After waiting 5secs, the main line cleans up and exits. Are there any particular issues with callbacks in Squeak? Do I need to compile/link with anything special? It doesn't seem like this should be a problem since Squeak is single-threaded. If anything, I would think that the return would be slower not quicker. BTW, usleep returns w/o error. Any ideas or pointers much appreciated! brad -- Brad Fuller (408) 799-6124 ** Sonaural Audio Studios ** (408) 799-6123 West San Jose (408) 799-6124 Cambrian ________________________________ Hear us online: www.Sonaural.com See me on O'Reilly: http://www.oreillynet.com/pub/au/2184

3 5

Color your methods when they are executed [was: instrumenting send on squeak-dev]
by Klaus D. Witzel 20 Nov '05

20 Nov '05

I've uploaded a new package Goya (to SqSource and SqMap) which paints methods with up to 25 colors, at the time they are executed. The changed VM (3.7.1, gcc 2.95.2) does 0 tinyBenchmarks '288939051 bytecodes/sec; 6979361 sends/sec' and the unchanged VM (also compiled by me) does 0 tinyBenchmarks '289429055 bytecodes/sec; 8627664 sends/sec' Methods can be colored dynamically in the running image (coloring survives snapshots). The implementation implants a "coloring" instance of a subclass of Association into the method's literal frame (same slot as the methodClass for super sends). This can be checked by the VM in O(1) time. If the VM finds that a colored method sends to a colored implementor, the coloring information is bitOr:'ed into the sender's and the receiver's "coloring" association. This is like edge coloring of a graph. Following the discussion of method coloring at Friday's Bern Smalltalk Gathering I also made a GoyaBrowser which views only those methods (and their respective classes and system categories) which satisfy some coloring condition, dynamically, depending on which colored methods are effectively executed. With Goya I found that besides of SmallInteger and LargePositiveInteger and Array>>#replaceFrom:to:with:startingAt: ByteArray>>#replaceFrom:to:with:startingAt: three other primitives fail and run their bytecode instead BitBlt>>#copyBits BitBlt>>#primDisplayString:from:to:map:xTable:kern: CharacterScanner>>#scanCharactersFrom:to:in:rightX:stopConditions:kern: The initial Goya package includes some examples on FileStream, Morph, System-Compiler and instance creation for illustrating the implementation. Note that I first tried to implement method coloring as an optional plugin but that would need to know the sending as well as the implementing method at the same time, which is apparently not available in the interpreterProxy interface. I am aware that I do open heart surgery and would appreciate any comment, critique and suggestion. A developer has already emailed me for making the changed VM available or else get rid of the VM changes (currently do my work on Win32 but am about to add Debian Sarge) but first I would like to receive some advise from the experts. Thank you in advance. /Klaus

1 0

Re: Cross platform plugin dev
by Brad Fuller 19 Nov '05

19 Nov '05

Ian Piumarta wrote: > Hi Brad, > >> I'm going thru the unix configuration doc and files to learn how it >> is configured for unix development. >> However, what if you have only Cross platform plugin files? They >> would go into the Cross subdirs. What have others done to create and >> build plugins that are cross platform? > > > If you don't need special treatment on Unix then all you need to do > is create the Cross/plugins/Whatever/whatever.c file (and any > attendant .h files) and run 'autoconf' to recreate the configure > script. Thereafter 'configure' will know about the plugin and will > attempt to build it. > >> Do you create your own hand-made Makefile (etc)? > > > You only need to do this if you have special compiler flags or header > directories that you need to pass to the compiler on Unix. In that > case look at Makefile.inc in one of the other plugin directories to > see typical things that you can do. For very unusual plugins you may > even need a complete 'Makefile.in' to replace the automatically > generated one entirely. (The vm has its own Makefile.in, for example.) > > You might also (in very demanding plugins) require configuration-time > options and tests, or even to disable the plugin entirely if required > libraries are not installed. If you put a file called 'acinclude.m4' > in your plugin directory, autoconf will include it in the configure > script at the appropriate moment. (See the other acinclude.m4 files > for typical things you can do.) Of course, you need to run > 'autoconf' again after every change to an acinclude.m4 file. > > But normally you won't need anything special: put the .c and .h files > in Cross/plugins/YourPlugin/ and run autoconf to rebuild the > configure script. See the 'RePlugin' for example, which has no Unix > files at all. > Thanks. I actually had it working before, but now I can't configure it. I can't remember which directory I placed the Makefile.inc! I'm kinda having some trouble following the directions. You wrote very clear directions but probably didn't follow them well ;-) I could not get config/configure (is that what you are referring to as 'autoconfig'? Or is that a new script?) to find my makefile.inc no matter where I put the plugin directory (although it did create the Makefile. ) But anyway.... Since I don't really have a unix specific plugin, I want to put it in Cross for now and I'll try that. Have you used VMMakerTool? If so, how do you use it to generate C files in the Cross directory? brad -- Brad Fuller (408) 799-6124 ** Sonaural Audio Studios ** (408) 799-6123 West San Jose (408) 799-6124 Cambrian ________________________________ Hear us online: www.Sonaural.com See me on O'Reilly: http://www.oreillynet.com/pub/au/2184

3 3

Unix VM Doc potential error -
by Brad Fuller 19 Nov '05

19 Nov '05

The documentation to manually configure the make for the unix vm/plugin seems incorrect. This in particular: ===================== ... $ cd bld Create the build environment by running the script configure which lives in the platforms/unix/config directory. Note: The configure script accepts lots of options. To see a list of them, run: `configure --help' Assuming you've created the blddir next to platforms, this would be: $ ../platforms/unix/config/configure Note: This assumes that the VMMaker sources are in `../src'.. ======================= If the src directory is in next to platforms and blddir (as the doc suggests is default), the config/configure script cannot find the vm directory because it looks under the src dir for it. if you VMMaker generate your sources in ../platforms/unix/src VMMaker places plugins.ext and plugins.int in that directory (I think that's who does it) and since vm is in that directory it configures correctly, Or am I just going in circles and I haven't found my tail yet? :-) === And Tim: If VMMakerTool does create plugins.ext, it doesn't seem to create it when generating individual plugins from the context menu. At least, I didn't see that it did. What I did was manually edit plugins.ext so that the Makefile for my plugin would be created by config/configure. I may be wrong about this, but I didn't see that it did. brad

1 0

Re: Cross platform plugin dev
by Brad Fuller 19 Nov '05

19 Nov '05

tim Rowledge wrote: > > On 18-Nov-05, at 5:39 PM, Brad Fuller wrote: > >> Another thing about VMMakerTool: >> How can you work on one plugin (as an example) and create c code for >> that one plugin without deleting all of the other plugin dirs? > > > Easy - use the context menu in the external plugins list to generate > just that one plugin. Unless I've broken it recently (always some > possibility) that is the way to generate your single plugin so that > you can cycle round generate-compile-test(since it autoloads)-unload > (with SmalltalkImage current unloadModule:'myPlugin')-rinse-and-repeat oh.. THATS what that is! Ok, that works! > >> I'm using the VMM38b branch and there are many plugin directories. >> But, if you drag over just one plugin and generate in VMMakerTool, >> it blows away all the others. > > Yah. It's a tricky problem of interlocks that reflects trying to make > a bunch of opinionated people happy some years ago. I think the help > text could do with a little more explanation. Yeah.. maybe a clearer note. Now I know what "list" means in this sentence: "You can also generate internal or external plugins singly, using the menus in the lists" I'll tell you that the "Clean Out" button is a dangerous button. Hit that accidentally and BAM your code is gone. thanks for your help, Tim. Now.. .working on getting config/configure to really configure all of this. I can't get it to find things. When I get one thing pointed right, it negates another. I'm going around in circle ;-) -- Brad Fuller (408) 799-6124 ** Sonaural Audio Studios ** (408) 799-6123 West San Jose (408) 799-6124 Cambrian ________________________________ Hear us online: www.Sonaural.com See me on O'Reilly: http://www.oreillynet.com/pub/au/2184

1 0

Cross platform plugin dev
by Brad Fuller 19 Nov '05

19 Nov '05

I'm going thru the unix configuration doc and files to learn how it is configured for unix development. However, what if you have only Cross platform plugin files? They would go into the Cross subdirs. What have others done to create and build plugins that are cross platform? Do you create your own hand-made Makefile (etc)? -- Brad Fuller (408) 799-6124 ** Sonaural Audio Studios ** (408) 799-6123 West San Jose (408) 799-6124 Cambrian ________________________________ Hear us online: www.Sonaural.com See me on O'Reilly: http://www.oreillynet.com/pub/au/2184

2 3

Squeak VM source is now at squeakvm.org
by goran＠krampe.se 18 Nov '05

18 Nov '05

Hi all! A while back the VM source home (SVN server) was moved by Ian Piumarta from the HP lab setup to squeakvm.org. The HP machine is frozen and now it also seems to be taken offline. This move was not publically announced on squeak-dev, but Ian probably just forgot. regards, Göran

2 1

Re: Success! Re: My Annual VM-building post (MacOS)
by Josh Gargus 17 Nov '05

17 Nov '05

(moving this over to vm-dev from squeak-dev) Aargh! But it still runs really slow! For example, a typical vm built by you gives the following result: '102481985 bytecodes/sec; 4680713 sends/sec' This is much faster than both a vm... built by me last week, gcc 4.0 '85676037 bytecodes/sec; 3241530 sends/sec' built by me a few minutes ago, gcc 3.3 '56338028 bytecodes/sec; 1730422 sends/sec' In fact, the one I built with gcc-3.3 is far worse than the gcc-4.0 one! Any ideas? I'll continue to play around with it. Thanks, Josh On Nov 17, 2005, at 10:51 AM, Josh Gargus wrote: > Thanks for the updates you checked in. > > I still had to add -fPIC to the cflags in order for it to build, > though. > > Josh > > > On Nov 10, 2005, at 2:13 PM, John M McIntosh wrote: > >> I'll note building with gcc 4.0 is a bad idea because the VM >> performance degrades... >> I'll post a XCode 2.1 aware project for the 38vmmaker tree and the >> main trunk once I get everything to compile. >> >> On 10-Nov-05, at 9:43 AM, Josh Gargus wrote: >> >>> Huzzah for perseverence! >>> >>> The auto-updated XCode project wasn't quite right; I had to make >>> the following tweaks: >>> - switch to use gcc-4.0 >> >> -- >> ===================================================================== >> ====== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 >> Corporate Smalltalk Consulting Ltd. http:// >> www.smalltalkconsulting.com >> ===================================================================== >> ====== >> >> > >

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev November 2005