Vm-dev November 2005

vm-dev@lists.squeakfoundation.org

15 participants
17 discussions

Re: Test VMMaker branch for 38b4 on SVN server
by Brad Fuller 17 Nov '05

17 Nov '05

Tim Rowledge wrote: >As a small experiment I've just made a branch on the SVN server that >_should_ contain a tree of platform files suitable for working with a 3. >8 image and the VMMaker38b4 on SM. > >It ought to come your way in response to >svn co http://squeak.hpl.hp.com/svn/squeak/branches/VMM38b4 > >This does NOT include the changes towards 64 bit cleanliness and thus >does not need the small changes that ought to be in the update stream. >If this seems to work, we'll try making a new branch for each future >version of VMMaker so that the head can be left as the dangerous place. > I suppose this link is gone: http://squeak.hpl.hp.com/svn/squeak/branches/VMM38b4 I couldn't get to it just now. Actually, do I even need this? Tim originally supplied this so I could learn VM building. But, I'm now creating just an external plugin. Do I even need a buildable VM to build one external plugin? Perhaps I can use the latest SVN just for the directory structure? How do others create a working environment for external plugin dev? brad

4 4

Creating new context classes for Exupery
by Bryce Kampjes 16 Nov '05

16 Nov '05

I've just started work on compiling blocks but unfortunately there isn't a spare slot in BlockContexts to hold a pointer to the natively compiled code so I'm thinking about creating context classes for Exupery. The new contexts will be removed when Exupery is shutdown or Exupery's code cache is initialised because they will hold pointers to compiled code which isn't saved with the image. However they will need a compact class number so they can be checked for. This is important because the GC needs to check if an object is a context so it can deal with the stack. If I use a compact class then the extra check will just be an extra integer comparison. I'll probably swap the position of the caller and the instruction pointer for Exupery's contexts. This way an integer check of either position will indicate if it's an Exupery compiled context or an interpreted context. Exupery's instruction pointers are pointers to compiled code tagged as integers. The caller or sender slot should always be a pointer object not a SmallInteger while both Exupery instruction pointers and interpreted instruction pointers are always SmallIntegers. Would checking the instruction pointers size be more sensible? In practise it would be safe but there's a risk that the code cache might be allocated at memory location 0 on some platforms. I'll need to use my own contexts for natively compiled methods as well once Exupery starts inlining methods. This is so that image level code will be able to hide the inlining or de-inline if necessary (say when single stepping in the debugger). Any objections? Bryce

2 2

plugin loads, but crash in shared library
by Brad Fuller 15 Nov '05

15 Nov '05

Hi All, I now assuming that I'm not linking the shared library correctly. Is there anything special that I need to understand and do with an external plugin calling a shared library? (i know, wide open question, sorry) I built the shared library, but it's built from the vendor's makefile and works perfectly fine as is. As mentioned in a previous msg, other apps can call this shared library fine with no problem. Maybe the library is linked incorrectly? However, there are no undefined references so something is finding the symbol. Here is the output of the makefile relevant to linking: /bin/sh /home/bfuller/projects/squeak/branches/platforms/unix/libtool --mode=link gcc -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -avoid-version -module -rpath /usr/local/lib/squeak/3.7-7 -o SoundPAPlugin.la SoundPAPlugin.lo patest_sine.lo -Wl,/usr/local/lib/libportaudio.so (if you've been following this saga, I couldn't get the Makefile.inc to be recognized so I manually edited the Makefile to include this shared library for resolving references) libtool/gcc experts: does that look right? Do I need to also add a runtime switch for the library at /usr/local/lib? -rpath? The environment var "LD_LIBRARY_PATH" is set to /usr/local/lib -- I assumed this was enough. Or, maybe I'm linking the shared library all wrong. Any pointers or docs would be helpful and 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

2 4

Re: newbie: plugin loaded?
by Brad Fuller 13 Nov '05

13 Nov '05

tim Rowledge wrote: > > On 11-Nov-05, at 12:41 PM, Brad Fuller wrote: > >> What is a way to determine if an external plugin has been loaded? >> Couldn't find this on the swiki. > > Smalltalk listLoadedModules will tell you all the modules actually > loaded *and in use* whether they are external or internal. Thanks, Tim and Burt! My primitive merely calls a cross platform file that plays a sine wave, entirely in C, for 5 seconds and then returns. I think the problem is that it can't find an external library. I receive this: $ ioLoadModule(/usr/local/lib/squeak/3.7-7/SoundPAPlugin): /usr/local/lib/squeak/3.7-7/SoundPAPlugin: undefined symbol: Pa_GetDeviceInfo Pa_GetDeviceInfo is in a library accessible to all (usr/local/lib/libportaudio.so). All of this works fine externally: i.e. the sine wave plays from the command line (of course, when I make the file with a main()). I call Pa_GetDeviceInfo from a Cross platform file: patest_sine.c file. I can see that both of my files compiled fine and landed in the 'src' directory: SoundPAPlugin.o patest_sine.o I assume these are linked and placed in: /usr/local/lib/squeak/3.7-7/SoundPAPlugin I further assume, that since the error reported is about Pa_GetDeviceInfo, the plugin is being called, but it can't find the library where Pa_GetDeviceInfo resides: usr/local/lib/libportaudio.so. Do I need to do something different with external libraries -- even though the system knows all about them? brad

2 6

newbie: plugin loaded?
by Brad Fuller 13 Nov '05

13 Nov '05

What is a way to determine if an external plugin has been loaded? Couldn't find this on the swiki. I see that the plugin has make'd and copied to the proper system dir along with the other plugins. But, my one primitive fails (which doesn't do much). I'm assuming that the plugin hasn't loaded (there is no initialization but I'm using Slang) 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

4 3

Archiving information from a plugin
by Alan Sibley 08 Nov '05

08 Nov '05

I hope this is the best mailing list for this question... I am writing a squeak plugin and have two questions. My plugin has internal objects that are modified by various primitives. I would like to archive this information from one run to the next. A) are squeak ids passed into my plugin ("oops")... are they only good for the single execution of the primitive (can I save these off in the plugin... and expect to see them around later?... does garbage collection move these guys?). B) is there a prescribed way to archive information from a plugin at "save image" time and later restore it at "load image" time? My plugin can create an ascii string to store off state. I could have a primitive save and restore the state... but how do I have these primitives called. Is there an existing hook for something like this. Thanks in advance, Alan

4 3

Awe and horror.
by Alan Grimes 01 Nov '05

01 Nov '05

As I begin to grasp the scope of the optimizations in the interpreter and C-Translator, I am filled with a sense of awe. These tweaks were obviously done with a deep knowledge of Smalltalk, C, the behavior of C compilers, and assembler. At the same time, I'm filled with horror as I realize the people who wrote these must of have sold their souls, left kidneys, and first born offspring in order to pull it off. While the VM, as it exists today, is adequate for conventional Squeak as it is presently used. Unfortunately, however, the scope and nature of its optimizations make it difficult to modify and extend. The non-obvious things the C-translator does make VM hacking extremely inhospitable to newcomers. For example, I would look at the class definition and would think to myself: OK, these "instance" variables will be put into a structure that can be instantiated by appropriate calls to C, and the class variables will probably end up being static variables in the same source file. -- thereby approximating the behavior of Smalltalk classes. Instead, class variables are optimized as constants, and while instance variables are put in a structure, there is no way to instantiate the structure or manage such instances should they be created. Much much worse, however, is that the C translator will behave differently depending on which class it is processing and apply special hacks where it thinks nobody will notice. -- The hapless newbie probably won't discover these hacks until he has read at least 500 messages... I'm going to try to fork my own version of the vmmaker intended to be much more flexible and robust to experimentation though, perhaps, a bit slower... (The current version of my custom VM is half as fast but still usable...) The current issue that I'm having trouble with is figuring out exactly how the CCode generator interfaces with the system wide compiler. I am especially curious as to how to implement scope-reduced variables. (variables declared within a block instead of a function...) How exactly are syntax elements mapped onto the translation classes? In any event, I hope to have an interesting variation on the VM technology someday... -- Friends don't let friends use GCC 3.4.4 GCC 3.3.6 produces code that's twice as fast on x86! http://users.rcn.com/alangrimes/

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev November 2005