Vm-dev May 2011

vm-dev@lists.squeakfoundation.org

36 participants
89 discussions

Re: Having trouble with 4.2 on Linux
by Ken Causey 25 May '11

25 May '11

Levente said: >The error message is correct, you should specify the return type as long. >There's no int type in FFI, probably because it's ambiguous (even in C) >and unnecessary. Thank you Levente. This was enough to get me farther and have the method compile. If I were planning to do anything serious with this I would certainly use trunk and take advantage of your fix, thanks for that also. I've fiddled with it a bit and the best result I have gotten so far is if I implement my AnFFITest class as a subclass of ExternalObject and put my method on the class side: testRand "simplest test I could think of" <cdecl: long 'rand' ()> ^self externalCallFailed This fails with 'unable to find function address'. Perhaps rand isn't a function or I need to do something more to indicate that the function is a libc function, or I've made some other mistake. Separately David has suggested that for my self-built VM I specify -m32 but if I do that with cmake/configure -CFLAGS=-m32 configure fails with 'no suitable type found' with the top of the stack 'vm/config.cmake:71 (TEST_BIG_ENDIAN). In all likelihood I'm not doing this right and I will continue to look around. However even with the normal build cmake gives a stern warning that we are using an accidental and deprecated feature (The source directory .../unix/npsqueak does not contain a CMakeLists.txt file). I'm using cmake 2.8.4 and I wonder if cmake has moved beyond our currently cmake configuration. I'll continue to mess with it and I welcome any suggestions anyone has. Ken

2 1

Re: [Pharo-project] Questions of understanding
by Igor Stasenko 25 May '11

25 May '11

On 25 May 2011 17:30, Friedrich Dominicus <frido(a)q-software-solutions.de> wrote: > Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > >> I have no idea. Maybe someone in the VM mailing list can help you. >> > Ok I finally got the serialPort access under Cog VM and Linux > I concede it is currently a hackerish solution a combination out of > Squeak sources and Cog sources with a good mixture of Cog > > So whomever may be "reponsible" can get in touch with me and I'll try to > work out a stable implementation on Linux. > > But I think there are a few problems with Pharo 1.3 and Cog. AFAIKT one > needs AbstractLauncher. I shamlessly stole it from Squeak. If I do > not have it and start my generated CogVM I just get an open window with > some black rectangle in the upper left. > This problem was mentioned at: > > http://code.google.com/p/pharo/issues/detail?id=4002 > > Now what did I have to do? > I downloaded the sources from squeak-vm and Cog and there are at least > two different C files and probably a header files with the prototyps: > The two files are > sqUnixSerial.c which is in platforms/unix/plugins/SerialPlugin > SerialPlugin in src/plugins/SerialPlugin > > It seems the first is the handwritten C-code > > The first is needed to "offer" the functionality and the later is > probabl seems t be the interface to Squeak. I guess this is generated > code from some Slang code which looks like this: > > parityType dataBits: dataBits inFlowControlType: inFlowControl outFlowControlType: outFlowControl xOnByte: xOnChar xOffByte: xOffChar > > | cString | > self primitive: 'primitiveSerialPortOpenByName' > parameters: #(ByteArray SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger ). > self var: #cString type: 'char *'. > cString := self allocateTerminatedString: deviceName. > self cCode: 'serialPortOpenByName( > cString, baudRate, stopBitsType, parityType, dataBits, > inFlowControl, outFlowControl, xOnChar, xOffChar)' > > which then write out the proper C code for that plugin. > > You see I'm still ignorant on how this is all supposed to work. > > Nevertheless copying the files at the proper places in the src and > platform tree. This codes get's compiled into the VirtualMachine. > > And I can use this "machine" for accessing the serial interfaces, (it > even works for '/dev/ttyUSBx' devices. For me this is a great thing > because I'm forced to access some periperal devices via serial lines. > > I need some extra hack in the generated file (I know this is "dirty" a > missing #define was introduced. I bet there is a better place for that > but in genrated code. But well it's just an intermediate step. > > If someone here may be interested just drop me a mail and with some help > we'll be able to modify the Cog sources cleanly to use this modified > Plugin for intefacing to serial lines in Linux. > In order to answer this question we have to see what you did. And for that, it would be good if you register on gitorious.org and then clone VM sources into your own branch and then push your changes there. Then we can analyze it and integrate into a main branch. > I'm also quite aware that the Smalltalk side of the code could need a > little attention: It looks like: > > > nextPutAll: aStringOrByteArray > "Send the given bytes out this serial port. The port must be > open. " > ^ port isString > ifTrue: [self > primWritePortByName: port > from: aStringOrByteArray > startingAt: 1 > count: aStringOrByteArray size] > ifFalse: [self > primWritePort: port > from: aStringOrByteArray > startingAt: 1 > count: aStringOrByteArray size] > > Which is kind of "unproper" IMHO.... > Please, create an issue on Cog issue tracker and place a changeset for language side changes there. You can also use that issue entry to describe your changes and point to the VM-side source code which you are changed. http://code.google.com/p/cog/issues/list Otherwise there is a risk, that your changes and comments will be buried under tons of other mails and will be lost. P.S. it is great that you were able to fix plugin & build VM with little help. If you have questions, do not hesitate to ask. We need people who are not afraid to get their hands dirty and to fix something in VM :) -- Best regards, Igor Stasenko AKA sig.

1 0

Re: [Pharo-project] Questions of understanding
by Mariano Martinez Peck 25 May '11

25 May '11

But I think there are a few problems with Pharo 1.3 and Cog. AFAIKT one > needs AbstractLauncher. I shamlessly stole it from Squeak. If I do > not have it and start my generated CogVM I just get an open window with > some black rectangle in the upper left. > This problem was mentioned at: > > http://code.google.com/p/pharo/issues/detail?id=4002 > > yes. Cog doesn't load in Pharo 1.3 anymore. We will fix it. > Now what did I have to do? > I downloaded the sources from squeak-vm and Cog and there are at least > two different C files and probably a header files with the prototyps: > The two files are > sqUnixSerial.c which is in platforms/unix/plugins/SerialPlugin > SerialPlugin in src/plugins/SerialPlugin > > It seems the first is the handwritten C-code > yes, everything under /platform is the hand written part and known as "platform code" > > The first is needed to "offer" the functionality and the later is > probabl seems t be the interface to Squeak. I guess this is generated > code from some Slang code yes, and that's what is known as "VM sources", the auto generated C code from SLANG that is usually placed in /src > which looks like this: > > parityType dataBits: dataBits inFlowControlType: inFlowControl > outFlowControlType: outFlowControl xOnByte: xOnChar xOffByte: xOffChar > > | cString | > self primitive: 'primitiveSerialPortOpenByName' > parameters: #(ByteArray SmallInteger SmallInteger > SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger > SmallInteger ). > self var: #cString type: 'char *'. > cString := self allocateTerminatedString: deviceName. > self cCode: 'serialPortOpenByName( > cString, baudRate, stopBitsType, parityType, > dataBits, > inFlowControl, outFlowControl, xOnChar, xOffChar)' > > which then write out the proper C code for that plugin. > > yep > You see I'm still ignorant on how this is all supposed to work. > > so do I :) > Nevertheless copying the files at the proper places in the src and > platform tree. This codes get's compiled into the VirtualMachine. > > And I can use this "machine" for accessing the serial interfaces, (it > even works for '/dev/ttyUSBx' devices. For me this is a great thing > because I'm forced to access some periperal devices via serial lines. > > I need some extra hack in the generated file (I know this is "dirty" a > missing #define was introduced. I bet there is a better place for that > but in genrated code. But well it's just an intermediate step. > > If someone here may be interested just drop me a mail and with some help > we'll be able to modify the Cog sources cleanly to use this modified > Plugin for intefacing to serial lines in Linux. > Eliot should be interested. But you didn't comment your changes. Maybe you can push them in git ? > > I'm also quite aware that the Smalltalk side of the code could need a > little attention: It looks like: > > > > nextPutAll: aStringOrByteArray > "Send the given bytes out this serial port. The port must be > open. " > ^ port isString > ifTrue: [self > primWritePortByName: port > from: aStringOrByteArray > startingAt: 1 > count: aStringOrByteArray size] > ifFalse: [self > primWritePort: port > from: aStringOrByteArray > startingAt: 1 > count: aStringOrByteArray size] > > > for this you can open a pharo issue -- Mariano http://marianopeck.wordpress.com

1 0

From: [Pharo-project] Questions of understanding
by Friedrich Dominicus 25 May '11

25 May '11

Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > I have no idea. Maybe someone in the VM mailing list can help you. > Ok I finally got the serialPort access under Cog VM and Linux I concede it is currently a hackerish solution a combination out of Squeak sources and Cog sources with a good mixture of Cog So whomever may be "reponsible" can get in touch with me and I'll try to work out a stable implementation on Linux. But I think there are a few problems with Pharo 1.3 and Cog. AFAIKT one needs AbstractLauncher. I shamlessly stole it from Squeak. If I do not have it and start my generated CogVM I just get an open window with some black rectangle in the upper left. This problem was mentioned at: http://code.google.com/p/pharo/issues/detail?id=4002 Now what did I have to do? I downloaded the sources from squeak-vm and Cog and there are at least two different C files and probably a header files with the prototyps: The two files are sqUnixSerial.c which is in platforms/unix/plugins/SerialPlugin SerialPlugin in src/plugins/SerialPlugin It seems the first is the handwritten C-code The first is needed to "offer" the functionality and the later is probabl seems t be the interface to Squeak. I guess this is generated code from some Slang code which looks like this: parityType dataBits: dataBits inFlowControlType: inFlowControl outFlowControlType: outFlowControl xOnByte: xOnChar xOffByte: xOffChar | cString | self primitive: 'primitiveSerialPortOpenByName' parameters: #(ByteArray SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger ). self var: #cString type: 'char *'. cString := self allocateTerminatedString: deviceName. self cCode: 'serialPortOpenByName( cString, baudRate, stopBitsType, parityType, dataBits, inFlowControl, outFlowControl, xOnChar, xOffChar)' which then write out the proper C code for that plugin. You see I'm still ignorant on how this is all supposed to work. Nevertheless copying the files at the proper places in the src and platform tree. This codes get's compiled into the VirtualMachine. And I can use this "machine" for accessing the serial interfaces, (it even works for '/dev/ttyUSBx' devices. For me this is a great thing because I'm forced to access some periperal devices via serial lines. I need some extra hack in the generated file (I know this is "dirty" a missing #define was introduced. I bet there is a better place for that but in genrated code. But well it's just an intermediate step. If someone here may be interested just drop me a mail and with some help we'll be able to modify the Cog sources cleanly to use this modified Plugin for intefacing to serial lines in Linux. I'm also quite aware that the Smalltalk side of the code could need a little attention: It looks like: nextPutAll: aStringOrByteArray "Send the given bytes out this serial port. The port must be open. " ^ port isString ifTrue: [self primWritePortByName: port from: aStringOrByteArray startingAt: 1 count: aStringOrByteArray size] ifFalse: [self primWritePort: port from: aStringOrByteArray startingAt: 1 count: aStringOrByteArray size] Which is kind of "unproper" IMHO.... Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

1 0

Re: Having trouble with 4.2 on Linux
by Ken Causey 25 May '11

25 May '11

David said: > Since you are on X86_64, make sure that you are compiling your VM in > 32-bit mode (-m32 compiler flag). FFI does not work on 64-bit platforms, > details at http://bugs.squeak.org/view.php?id=7237. > > FYI, this can definitely be fixed (the patches were done a few years ago), > but I would frankly be reluctant to try taking it on right now because it > is a complex set of changes that must be coordinated in the platform support > code, slang, and images, and there are quite a lot of other things going > on with VMs these days, including Eliot's work on a new FFI. > > The status of the 64-bit fixes and testing as of May 2008 is in the thread > at http://lists.squeakfoundation.org/pipermail/vm-dev/2008-May/001945.html > > Dave Thanks Dave, I will try rebuilding the stock VM tomorrow with the suggested flag and see what happens. However I will take this opportunity to update everyone on why I finally got fed up with it today. I thought to myself if the test functions were not being included in the plugin(and my cursory inspection suggests the cmake configuration does not include ffi-test.*) then perhaps the simplest thing I could do would be to create a simple interface to rand. So I created a new subclass of ExternalLibrary and tried to add a testRand instance method. However as soon as I finished typing '<cdecl:' I started getting debuggers popping up for every keypress related to parsing, I suspect having to do with Shout. Yet I check the preferences and under Browsing Shout and syntaxHighlightingAsYouType (going from memory) are not enabled. But in fact the syntax is being colored as I type. I can't figure out how to stop it. So I just type away and ignore the debuggers resulting in testRand "Test rand" <cdecl: int 'rand' ()> ^self externalCallFailed and I try to accept that but it will not accept it insisting that there should be a return call type in the cdecl line even though I think I've typed one in there. I also tried <cdecl: int 'rand' (void)> as I'm not sure which if either of these is correct, but the same result happens in both cases. Ken

3 2

Having FFI trouble with 4.2 on Linux
by Ken Causey 25 May '11

25 May '11

Matthew on #squeak was having trouble with FFI on Ubuntu so I thought I would give it a try on my Debian Testing system. I should note that I am on X86_64 while Matthew is on i386/i686. I think Matthew will follow up with details about his experience. First I've not been Squeaking much in some time so all I have handy on my current development system is a 4.2-all-in-one in case I want to help answer a #squeak question. So I started out using this image and VM. The image is the stock 4.2 image unmodified. I added 'source.squeak.org/FFI' to Monticello and installed http://source.squeak.org/FFI/FFI-Pools-eem.3.mcz http://source.squeak.org/FFI/FFI-Kernel-mtf.23.mcz http://source.squeak.org/FFI/FFI-Examples-ar.1.mcz http://source.squeak.org/FFI/FFI-Tests-jcg.4.mcz http://source.squeak.org/FFI/FFI-Unix-mtf.4.mcz in that order. In this configuration if I run the tests I get 1 success, 1 failure, and 21 errors. In the process I also tried earlier -ar versions of the packages with much the same result. Watching with strace it appears it is unable to find the ffiTest* symbols in the supplied so.SqueakFFIPrims and if I look at it with objdump they do not appear to be there. Note that this file is only 23572 bytes in size. Next I tried building 4.4.7-2357 (the latest Unix VM and the same distributed in the all-in-one) myself. After a few fumbles I got that build with an FFI plugin but when I try the tests with that build the image immediately crashes: "Segmentation fault 24014104 ExternalFunction>invokeWith:with:with:with: 24011904 FFIPluginTests>testConstructedCharCall 24011812 TestCase>performTest 24011708 TestCase>runCase 24011616 BlockClosure>on:do: 24011524 TestCase>timeout:after: 24011432 BlockClosure>ensure: ...." I can provide more info if desired. Note that the so.SqueakFFIPrims with my own build is 38353 bytes in size and I can confirm it has the ffiTest* symbols. I have not as of yet tested this with strace. As part of the process I also tried cog 2382 and it works just fine, all the tests pass. I simply downloaded the linux binary tgz, extracted it, and ran it in place with the very same 4.2 stock image. Oh, and cog's SqueakFFIPrims is 260838 in bytes. Totally different implementation? Note that in all cases I repeated the entire process of installing the FFI packages manually. Ken

4 3

Performance of primitiveFailFor: and use of primFailCode
by David T. Lewis 25 May '11

25 May '11

I have been trying to gradually update trunk VMMaker to better align with oscog VMMaker (an admittedly slow process, but hopefully still worthwhile). I have gotten the interpreter primitives moved into class InterpreterPrimitives and verified no changes to generated code. This greatly reduces the clutter in class Interpreter, so it's a nice change I think. My next step was to update all of the primitives to use the #primitiveFailFor: idiom, in which the successFlag variable is replaced with primFailCode (integer value, 0 for success, 1, 2, 3... for failure codes). This would get us closer to the point where the standard interpreter and stack/cog would use a common set of primitives. A lot of changes were required for this, but the resulting VM works fine ... except for performance. On a standard interpreter, use of primFailCode seems to result in a nearly 12% reduction in bytecode performance as measured by tinyBenchmarks: Standard interpreter (using successFlag): 0 tinyBenchmarks. '439108061 bytecodes/sec; 15264622 sends/sec' 0 tinyBenchmarks. '433164128 bytecodes/sec; 14740358 sends/sec' 0 tinyBenchmarks. '445993031 bytecodes/sec; 15040691 sends/sec' 0 tinyBenchmarks. '440999138 bytecodes/sec; 15052960 sends/sec' 0 tinyBenchmarks. '445993031 bytecodes/sec; 14485815 sends/sec' After updating the standard interpreter (using primFailCode): 0 tinyBenchmarks. '393241167 bytecodes/sec; 14066256 sends/sec' 0 tinyBenchmarks. '392036753 bytecodes/sec; 15040691 sends/sec' 0 tinyBenchmarks. '393846153 bytecodes/sec; 14272953 sends/sec' 0 tinyBenchmarks. '400625978 bytecodes/sec; 14991818 sends/sec' 0 tinyBenchmarks. '393846153 bytecodes/sec; 15176750 sends/sec' This is a much larger performance difference than I expected to see. Actually I expected no measurable difference at all, and I was just testing to verify this. But 12% is a lot, so I want to ask if I'm missing something? The changes to generated code generally take the form of: Testing success status, original: if (successFlag) { ... } Testing success status, new: if (foo->primFailCode == 0) { ... } Setting failure status, original: successFlag = 0; Setting failure status, new: if (foo->primFailCode == 0) { foo->primFailCode = 1; } My approach to doing the updates was as follows: - Replace all occurrences of "successFlag := true" with "self initPrimCall", which initialize primFailCode to 0. - Replace all "successFlag := false" with "self primitiveFail". - Replace all "successFlag ifTrue: [] ifFalse: []" with "self successful ifTrue: [] ifFalse: []". - Update #primitiveFail, #failed and #success: to use primFailCode rather than successFlag. - Remove successFlag variable. Obviously I don't want to publish the code on SqS/VMMaker, but I can mail an interp.c if anyone wants to see the gory details (It is too large to post on this mailing list though). Any advice appreciated. I suspect I'm missing something basic here. Thanks, Dave

5 22

Re: [Pharo-project] [Ann] Ephemerons for Cog
by Igor Stasenko 25 May '11

25 May '11

On 24 May 2011 02:47, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > What is Ephemerons? > http://portal.acm.org/citation.cfm?id=263733&coll=portal&dl=ACM Here the paper, if Eliot's explanation is not enough. > Alexandre > > > > Le 23 mai 2011 à 20:43, Igor Stasenko <siguctua(a)gmail.com> a écrit : > >> I felt a bit hacky today and decided to implement Ephemerons. >> >> I tried to run it on both StackVM and Cog VMs, >> it seems to work fine (at least all 4 tests, which my brain were >> capable to produce, are green. ;) >> >> >> You can find the VM code on SqS/VMMaker in package: >> VMMaker-oscog-IgorStasenko.67 >> >> Also, i created a separate issue on Cog issue tracker to track it. >> http://code.google.com/p/cog/issues/detail?id=44 >> >> The implementation may contain a bugs. So, it needs review and testing. >> Now i would like all interested parties to give a feedback and help >> integrating it into our production images. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- Best regards, Igor Stasenko AKA sig.

4 15

Re: Having FFI trouble with 4.2 on Linux
by Ken Causey 24 May '11

24 May '11

Correction: The slightly large so.SqueakFFIPrims in my self-built 4.4.7-2357 unix VM DOES NOT have any ffiTest* functions. I apologize, I'm starting to mix up the various cases I have tried. The much larger SqueakFFIPrims from Cog does have these. Ken

1 0

looking for feedback on Cocoa Cog MT VM
by Esteban Lorenzano 24 May '11

24 May '11

Hi, finally, after two months of suffering, thanks to John, I managed to fix a huge bug on cocoa cog vms that was showing up on latest cog and cog mt versions. Now, I think it is working pretty well, and with a good set of plugins: internal plugins: #(#ADPCMCodecPlugin #BMPReadWriterPlugin #BalloonEnginePlugin #BitBltSimulation #ClipboardExtendedPlugin #DSAPlugin #DeflatePlugin #DropPlugin #FFTPlugin #FilePlugin #FloatArrayPlugin #GeniePlugin #HostWindowPlugin #JPEGReadWriter2Plugin #JPEGReaderPlugin #KlattSynthesizerPlugin #LargeIntegersPlugin #Matrix2x3Plugin #MiscPrimitivePlugin #RePlugin #SecurityPlugin #SocketPlugin #SoundCodecPlugin #SoundGenerationPlugin #SoundPlugin #StarSqueakPlugin #SurfacePlugin) external plugins: #(#ThreadedIA32FFIPlugin #IA32ABIPlugin #UUIDPlugin #FloatMathPlugin #AsynchFilePlugin #SerialPlugin #Mpeg3Plugin #CroquetPlugin #JoystickTabletPlugin #MIDIPlugin #B3DAcceleratorPlugin #LocalePlugin) I want to release a stable Cocoa VM version by this month, so I'm looking for some guys who can test it and provide me some feedback, in case something is wrong. So... please, use it! :) cheers, Esteban

7 21

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2011