- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Linux VM microbenchmarks

by Bryce Kampjes

On Sat, 2010-04-03 at 22:19 +0200, Hilaire Fernandes wrote: > Laurent, > > I runned the same benchmark with Exupery, here is > > Exupery > 202371541 bytecodes/sec; 5948654 sends/sec > 201574803 bytecodes/sec; 5948654 sends/sec > 201416207 bytecodes/sec; 5933632 sends/sec > 202531645 bytecodes/sec; 5903814 sends/sec > 201892744 bytecodes/sec; 5938631 sends/sec > > > -O2 (compiled source code from the archive you provided) > 87372013 bytecodes/sec; 4436220 sends/sec > 86544962 bytecodes/sec; 4501376 sends/sec > 86253369 bytecodes/sec; 4507132 sends/sec > 86253369 bytecodes/sec; 4487049 sends/sec > 87372013 bytecodes/sec; 4498503 sends/sec > > You better check with Bryce. The Exupery build is just whatever ./config/configure decides to use, nothing special here. I do make sure that the gawk gnuification runs. It's a very vanilla but a bit dated C VM build environment. Bryce

April 5, 2010

Re: [Pharo-project] [squeak-dev] Re: A small idea how to get closer to hardware with small efforts :)

by Igor Stasenko

On 5 April 2010 15:42, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Mon, Apr 05, 2010 at 03:13:51PM +0300, Igor Stasenko wrote: >> Here the proof of concept implementation. > > >> So, here the questions, which i like to be answered: >> 1. reserve a numbered primitive > > Probably a named primitive in the interpreter is best, see comment in > John's new primitiveMicrosecondClock. I don't think that there is any > performance implication once the primitive name has been resolved once. > this is true, but numbered primitive could be inlined into an interpret() loop. Then this will make some difference :) >> 2. discuss the calling convention >> 3. add a 'platform id' code to VMMaker, and let language side know , >> on which platform id VM currently runs on (through additional >> primitive) > > I'm not sure how to handle #3, but there are a lot of different CPUs > and operating systems out there, not to mention all the different modes > of say an Intel CPU. So it may not be trivial to answer the question > "can this snippet of compiled code be executed in my current runtime > environment". > Well, a 2 bytes for code gives us 65536 variants. If this is not enough, we could use 32 bits for platform id code. Also, i thinking , maybe we could use masks for platform id, so, then one could generate/use the same native code for multiple kinds of OS-es. But then , a number of variants will be much more limited, because platform id will be treated as a bit field, instead of integer value. > Dave > > > -- Best regards, Igor Stasenko AKA sig.

April 5, 2010

Re: [Pharo-project] [squeak-dev] A small idea how to get closer to hardware with small efforts :)

by Igor Stasenko

On 5 April 2010 16:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > igor > > I'm confused. > Do you want to write C code in our smalltalk editor? (as in Smalltalk/X) err.. no. why i would want that, if i can just generate native code directly? We could use Exupery for generating it, with slight modifications. Or implement different native code generator. > Where the native code is coming? > Who compiles it? > Can I edit it? > There is no any implications where the native code comes from. It could be from compiler, implemented in smalltalk, or may be stored in some file.. not really matters. And yes, you can edit the code and generate it dynamically. If you look at example of how i did run a native code routine, it creates a native code on the fly, code := #(184 85 0 0 0 195) asByteArray. trailer nativeCode: code platformId: 1. method := (self class methodDict at: #theStub) copyWithTrailerBytes: trailer. and then runs it, by invokind a generated method. Here, the #(184 85 0 0 0 195) is an x86 instructions: mov eax, (42 << 1 +1) ret so, when you run it, a native routine returns a 42 smallinteger. > Do you have a scenario in mind to help understanding what is your vision behind your suggestion? > Stef > > On Apr 5, 2010, at 10:13 AM, Igor Stasenko wrote: > >> Hello again, >> >> it is about running a native code , stored in compiled methods. >> >> All we need is: >> >> a) allow code execution for object memory. On most platforms this is >> trivial - just pass additional flags to virtual memory allocation >> functions. >> b) add a single primitive 'call a native code' >> c) use a special compiled method trailer, which will store the native >> code inside itself >> >> Then we could place any native code inside a compiled method and use a >> single primitive to run this code. >> This is quite simple thing, given that both pharo and squeak adopted >> method trailers, so >> a primitive, before running the code, needs few checks: >> - a method's trailer format is valid (we could reserve a terminal >> byte value for that) >> - a native code, placed inside a method trailer is targeted for same >> platform as currently running on >> >> if not, then primitive will simply fail, and interpreter will run the >> method's bytecode, which , depending on a situation, can check if it >> can recompile the code >> (if platform doesn't match) or use a workaround. >> The only limitation of such approach, that native code, placed in >> compiled method should be relocate-agnostic, i.e. >> never use absolute jumps, only relative ones and so on. >> >> Also, we could force, that code using a specific calling convention, >> so it will be easy to fetch values from stack and other useful stuff >> from interpreter/object memory (like passing an interpreterProxy >> pointer). >> This could be a good answer in generating a trampoline code for >> FFI/Alien on the fly. >> >> What you think? >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 5, 2010

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...

by nullPointer

jarober says: >The reason these "Smalltalk for .NET" and "Smalltalk for the JVM" >projects never seem to come off is simple - Smalltalk isn't just flat >text in an editor. Smalltalk is the entire interactive environment. >It would be fairly simple to get a syntax parser, but it wouldn't be >Smalltalk. It would be Ruby or Python with Smalltalk syntax. >Somewhat useful perhaps, but not really Smalltalk. :( Hopefully it would have sufficient knowledge to be able to do something thus. Sorry, but I believe that it is the way that had to take commercial Smalltalk. It surprises to me that Cincom and company do not see it. Regards. -- View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 5, 2010

[Pharo-project] A port of Pharo: Redline Smalltalk ...

by Torsten Bergmann

>Someone knows the posibilities of implement a Smalltalk environment in MONO >.NET? Read the comments from around 23th of March at http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/ca5… Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

April 5, 2010

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...

by StÃ©phane Ducasse

On Apr 5, 2010, at 7:27 PM, nullPointer wrote: > > Someone knows the posibilities of implement a Smalltalk environment in MONO > .NET? I see projects like > http://ajlopez.wordpress.com/2008/07/14/ajtalk-a-smalltalk-like-interpreter/ > or too > http://www.refactory.com/Software/SharpSmalltalk/ John brant is the father of the refactoring browser. He did this experience to understand the problem for example of integer representation and others Stef > > but I will like know the guruÂ´s opinion. > > Regards. > -- > View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1750615p1751812.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 5, 2010

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...

by nullPointer

Someone knows the posibilities of implement a Smalltalk environment in MONO .NET? I see projects like http://ajlopez.wordpress.com/2008/07/14/ajtalk-a-smalltalk-like-interpreter/ or too http://www.refactory.com/Software/SharpSmalltalk/ but I will like know the guruÂ´s opinion. Regards. -- View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1750615p1751812.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 5, 2010

Re: [Pharo-project] New step in Pharo modularity

by Mariano Martinez Peck

On Mon, Apr 5, 2010 at 3:27 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > 1) There are packages that should NOT be part of the core, but they are not >> also dev tools. For example, ObjectTracer, ObjectViewer, Morph examples, >> Sound, ImageSegment (?) etc. So...where do we put them ? >> > > I would imagine to have each package in a dedicated SqueakSource > repository, pretty much the same way we have OB, RB, NewInspector. > Yes, actually, the repository was alrady created in SqueakSource under the name of PharoNonCorePackages. > From what you wrote, I understand that you wish to create an intermediary > layer, PharoNonCorePackages > In that case: > Pharo = PharoVeryCore + PharoNonCorePackages + PharoDev > Is this what you intend ? Exactly. > Ideally, I do not see a valid reason for PharoNonCorePackages to be: each > package can happily live in its own SS rep. Yes, they can also live in their own repository. But I think it is easier to have the all together in the same repository. Mostly because I don't think there will be too much packages for the same repository. I mean, all those packages are little and seem not to be very related to each other...so it is not like a big project where you need a repository because you have a lot of packages for the same project. In this case we will probably have one package. > Moreover, this could easily create confusion. Why ? What is the difference with the Pharo repository for example ? > But for practical reason, it could make your life easier. > > yes! > Cheers, > Alexandre > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 5, 2010

Re: [Pharo-project] Problem loading Exupery on PharoCore 1.0

by Bryce Kampjes

You can safely ignore this. Mondrian and GraphViz is only used for inspectors to view the generated code and intermediate languages. The easiest way to resolve them would be to load GraphViz and Mondrian from the Exupery repository. It should be easy to port Exupery forward to the latest Mondrian releases but may take a few very minor and localised code changes. Bryce On Sun, 2010-04-04 at 10:23 +0200, Lukas Renggli wrote: > AFAIK, Exupery uses Mondrian to visualize code generation/optimization/... > > Lukas > > On 4 April 2010 10:19, Tudor Girba <tudor.girba(a)gmail.com> wrote: > > Hi Laurent, > > > > Something is wrong. MOAbstractLayout and MOGraphVizLayout come from > > Mondrian. Were these by mistake somehow added as dependencies to Exupery? > > > > Doru > > > > > > On 4 Apr 2010, at 10:06, laurent laffont wrote: > > > >> Hi, > >> > >> I want to try to build Exupery VM. On PharoCore 1.0 I do: > >> > >> Gofer new > >> squeaksource: 'MetacelloRepository'; > >> package: 'ConfigurationOfVMMaker'; > >> load. > >> > >> (ConfigurationOfVMMaker project version: '1.2') load. > >> > >> Then > >> > >> Gofer new > >> squeaksource: 'Exupery'; > >> package: 'Exupery'; > >> load. > >> > >> I have this error: > >> > >> This package depends on the following classes: > >> MOAbstractLayout > >> You must resolve these dependencies before you will be able to load these > >> definitions: > >> MOGraphVizLayout > >> MOGraphVizLayout>>doExecute: > >> MOGraphVizLayout>>findTopLeftCorner: > >> > >> > >> I suppose I need GraphViz package > >> > >> Gofer new > >> squeaksource: 'GraphViz'; > >> package: 'GraphViz'; > >> load. > >> > >> But when I load it I have a Syntax Error: > >> > >> runWithSystemFramework: string > >> <> expected ->apicall: short 'system' (char*) module: > >> 'System.framework'> > >> > >> ^ self externalCallFailed > >> > >> Laurent Laffont > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > www.tudorgirba.com > > > > "It's not how it is, it is how we see it." > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > >

April 5, 2010

Re: [Pharo-project] [squeak-dev] A small idea how to get closer to hardware with small efforts :)

by StÃ©phane Ducasse

igor I'm confused. Do you want to write C code in our smalltalk editor? (as in Smalltalk/X) Where the native code is coming? Who compiles it? Can I edit it? Do you have a scenario in mind to help understanding what is your vision behind your suggestion? Stef On Apr 5, 2010, at 10:13 AM, Igor Stasenko wrote: > Hello again, > > it is about running a native code , stored in compiled methods. > > All we need is: > > a) allow code execution for object memory. On most platforms this is > trivial - just pass additional flags to virtual memory allocation > functions. > b) add a single primitive 'call a native code' > c) use a special compiled method trailer, which will store the native > code inside itself > > Then we could place any native code inside a compiled method and use a > single primitive to run this code. > This is quite simple thing, given that both pharo and squeak adopted > method trailers, so > a primitive, before running the code, needs few checks: > - a method's trailer format is valid (we could reserve a terminal > byte value for that) > - a native code, placed inside a method trailer is targeted for same > platform as currently running on > > if not, then primitive will simply fail, and interpreter will run the > method's bytecode, which , depending on a situation, can check if it > can recompile the code > (if platform doesn't match) or use a workaround. > The only limitation of such approach, that native code, placed in > compiled method should be relocate-agnostic, i.e. > never use absolute jumps, only relative ones and so on. > > Also, we could force, that code using a specific calling convention, > so it will be easy to fetch values from stack and other useful stuff > from interpreter/object memory (like passing an interpreterProxy > pointer). > This could be a good answer in generating a trampoline code for > FFI/Alien on the fly. > > What you think? > > -- > Best regards, > Igor Stasenko AKA sig. >

April 5, 2010