Exupery

exupery@lists.squeakfoundation.org

107 discussions

trying to build VM for Win32
by Andrew Tween 22 Sep '06

22 Sep '06

Hi Bryce and all, I am trying to build an Exupery VM for Win32. Question 1. - has anyone successfully done this? Question 2. - I get this error when compiling - gnu-interp.c: In function `exuperySetupMessageSend': gnu-interp.c:4567: `foo' undeclared (first use in this function) Looking at the corresponding method in Interpreter, I see... [(receiverClass < youngStart and: [picPosition ~= 0]) ifTrue: [self cCode: '*(int *) (picPosition + 12) = foo->receiverClass' What is 'foo' ? Does this give any hints to what I am doing wrong? I am using 3.8-6665full.image, VMMaker-wbk.35, (I installed this first) Exupery-wbk.195 (it also fails with .197), I got the vm source from http://squeakvm.org/svn/squeak/tags/unix-3.7-7 and I installed the files from http://www.kampjes.demon.co.uk/vms/exuperyVMFiles.tz Cheers, Andy

3 11

[Ann] Exupery VM for Solaris10/x86
by Patrick Mauritz 18 Sep '06

18 Sep '06

Hello people, with some help from Bryce, I've built the VM with Exupery plugin on Solaris 10/x86 and created a package. You can get it from http://ftp.squeak.org/Exupery/vms/exupery-vm-0.09-solaris.pkg and install it with pkgadd. The VM is based on unix-3.7-7 and contains everything except AsynchFilePlugin (which won't work on Solaris), MiscPrimitivePlugin (which won't build), and all the plugins not available on unix platforms, of course. It's also built without iconv support, as squeak depends on gnu iconv behaviour ("MACINTOSH" table doesn't exist, "MAC" table, given as alternative, won't cooperate with utf-8, so is useless, too). Also note that the package is built on Solaris 10u2 (06/06), so it might, or might not work on older releases. The VM passed all but a few tests in Exupery's test suite, some of which are known-broken. You still have to get yourself an image and the smalltalk part of Exupery to try it. Have Fun, Patrick Mauritz

3 2

[ANN] Exupery 0.09 now released.
by Bryce Kampjes 09 Sep '06

09 Sep '06

Exupery 0.09 includes a bug fix for a bug found by Yakov. Exupery 0.08 would stop the image being saved if it was run by a non-Exupery VM. There is a simple work around. Exupery 0.09 also includes dynamically inlined primitives. Primitive inlining is done by reading information out of the polymorphic inline caches. More primitives will need to be implemented before this provides a real world speed improvement but at least now Exupery will attempt to compile and inline primitives. Releases should be more frequent as Exupery moves towards a 1.0. It would be helpful if a few people began to experiment with using Exupery. Feedback on what needs to be done to provide a 1.0 release would be useful. At the moment both bug fixes and more primitives are required. Bryce

1 0

Preparing for Exupery 0.09.
by Bryce Kampjes 08 Sep '06

08 Sep '06

Yakov found a bug in Exupery 0.08. It is is not possible to save the image after loading Exupery using a stock VM. This is because Exupery now needs to clean up the code cache before saving and that code calls an Exupery primitive. The work-around is to modify the method Exupery>>shutDown shutDown self initialiseExupery Either comment out the call to initialiseExupery or use #on:do: to catch all errors. Because of this bug, I'm now preparing to release the current development code. After running the stress test, I've caught a bug in my current implementation of #at:. I'm going to fix this the release. Exupery 0.09 has dynamically inlined primitives. It can only compile #at: and #at:put: for pointer objects and instance variable getter primitives. More primitives are coming, but this bug deserves a release and I'd rather release the current development work than back-port a fix. A good back port would only touch two methods and a hacked fix would touch one method. Bryce

1 0

Exupery 0.08 is nearly ready.
by Bryce Kampjes 22 Aug '06

22 Aug '06

Exupery 0.08 is nearly ready for release. This version can compile methods with blocks and super sends. arithmaticLoopBenchmark 1398 compiled 92 ratio: 15.196 bytecodeBenchmark 2460 compiled 433 ratio: 5.681 sendBenchmark 1580 compiled 693 ratio: 2.280 doLoopsBenchmark 1084 compiled 642 ratio: 1.688 largeExplorers 485 compiled 520 ratio: 0.933 compilerBenchmark 943 compiled 853 ratio: 1.106 Cumulative Time 4853 compiled 1510 ratio: 3.213 1,166,287,015 bytecodes/sec; 16,761,970 sends/sec There is a precompiled VM for 0.08 here: http://ftp.squeak.org/Exupery/vms/exupery-vm-0.08.tz The current numbers are no better than before. The compiler benchmark may be able to be improved by tweaking the profiler that drives compilation. The largeExplorers benchmark spends most of it's time in a primitive doing point creation. It should be possible to improve the compiler benchmark now by tweaking the profiler that drives compilation. The current plan is to finish off dynamically inlined primitives next which should speed up largeExplorers. The bytecodeBenchmark currently inlines the #at: and #at:put: but this requires manually specifying the inlining. For this optimisation to be practical, it needs to be driven by dynamic type feedback. The remaining things for a 1.0 release are: * Finish dynamically inlined primitives * Implement enough primitives to provide a nice speed improvement for normal code. * Add interrupt checking to compiled code. * More testing and debugging. Comments? Bryce

2 1

A bug due to doing the right thing
by Bryce Kampjes 08 Jul '06

08 Jul '06

I decided to move the native instruction pointer into the same slot as the interpreted instruction pointer as this appeared to be the right thing to do. The advantage of maintaining the interpreted instruction pointer was an natively compiled context could at any time, except when it was executing, be executed by the interpreted. That has been a great help because it made integration much easier back before blocks as I only needed to handle the cases that I wanted to. Unfortunately natively compiled blocks can not use the same format as interpreted blocks as there's no spare slot to use for the natively compiled instruction pointer. One of the reasons that moving the instruction pointer is the correct thing to do is it will not introduce new bugs but it will make rare bugs more common. A bug that would only occur for a native block will now occur for native methods as well. This is a good thing as it makes the bugs easier to find. Another reason is I'll need to change the native method context format to introduce full method inlining. One of the remaining bugs that showed up after moving the native instruction pointers was happening due to the integration code for process switching. Originally there had been no such code however as a native method context could be interpreted some problems were hidden. I think I've just figured out this bug. There's one compiled method Delay>>wait. To create the bug it's also necessary to run the GraphVizBaseTests. The system seems to survive fine executing normally even though Delay>>wait is called often. Here's a log of it: 7ba84330 Entering exuperyReturn Delay>wait 7ba84330 Entering primitiveWait Delay>wait 7ba84330 entering transferTo: from Delay>wait 7bf95d1c Entering exuperyReturn Delay>wait 7bf95d1c Exiting exuperyReturn [] in UnixOSProcessAccessor>grimReaperProcess 7bf95d1c transfered to [] in UnixOSProcessAccessor>grimReaperProcess exiting transferTo: 7bf95d1c Exiting primitiveWait [] in UnixOSProcessAccessor>grimReaperProcess 7bf95d1c Exiting exuperyReturn BlockContext>repeat 7bf95d1c primitiveValue failed in BlockContext>repeat 7bf95d1c primitiveValue failed in BlockContext>repeat The first number is the address of the process object. What's happening is the first process returns into a native Delay>>wait which calls Semaphore>>wait (the primitiveWait in the logs). The primitiveWait transfers execution to the new process then tries to execute native code (so an interpreted process can transfer control to a natively compiled process). It executes the return from method code natively moving control into the block in grimReaperProcess. The primitive wait returns back into the native code which called primitiveWait. This native code then natively performs a method return moving execution up to BlockContext>>repeat. Block context repeat now tries to re-execute the block which fails because it has never returned so appears to be still executing. The bug is because the simplistic way I tried to introduce basic support for returning into compiled methods doesn't handle the case where the transferring method was compiled as well as the returning method. Up until now, I've been able to ignore how process switching happens because it always happens on the other side of a message send. I'm sure that there's been a few subtle unrepeatable bugs caused by me ignoring it. The solution is to redo the integration code so that it'll correctly handle both leaving native code and leaving interpreted code correctly. It shouldn't be hard but it will require a bit more understanding than I had when I tried the first time. Bryce

1 0

Adding argument count checking to Exupery.
by Bryce Kampjes 03 Jun '06

03 Jun '06

I've just run into a minor issue while adding argument count checking to natively compiled blocks. A block needs to check that it's getting called with the right number of arguments when it's valued. The interpreter's BlockContexts contain an argument count so it's easy to do the check. ExuperyBlockContexts don't and don't have any spare slots. The reason there's no spare slots is compiled contexts don't use the interpreted instruction pointer. The instruction pointer is nilled out occasionally so it's not suitable to hold the argument size. My options are: 1) Rejig compiled contexts so compiled MethodContexts are the closer as ExuperyBlockContexts then use the old instruction pointer to hold the compiled instruction pointer. 2) Do the argument check in compiled code as the compiler knows how many arguments there should be. The problem here is the compiled code would need to do a message send which means adding a selector to the special objects array. Either is possible. It's just a choice of costs and benefits. At the moment, I'm favouring rejigging compiled contexts so that compiled methods are closer to compiled blocks. Compiled methods are the way they are because it made it easier to bootstrap running compiled code. There's a spare slot in an interpreted MethodContext that's used to hold the native instruction pointer. This way if Exupery is removed a natively compiled MethodContext can be executed by a non Exupery VM. I'm thinking about moving the compiled instruction pointer to the normal instruction pointer slot for both compiled blocks and compiled methods. For now, I'll probably stick with using the same method context class for both natively compiled MethodContext's and interpreted MethodContexts. This means that natively compiled methods can continue to share the interpreters context recycling code. Full method inlining will require inlined methods to use a separate class so they can behave differently in the debugger. They need to behave differently to hide being inlined. Bryce

1 0

Re: Getting to 1.0 as soon as possible
by Chris Muller 06 Feb '06

06 Feb '06

> My plan is to release a 1.0 as soon as possible. > That's a release of > Exupery that is generally useful, even if only for a > single platform. That's good news Bryce! A blazing Squeak, if stable, would be truly compelling. Are you planning support for all three major platforms? I take it there is no (Slangy) way to make Exupery platform-independent? Regards, Chris

2 1

Getting to 1.0 as soon as possible
by Bryce Kampjes 05 Feb '06

05 Feb '06

My plan is to release a 1.0 as soon as possible. That's a release of Exupery that is generally useful, even if only for a single platform. The road map to 1.0 is: 0.08: * Compiled blocks * Super Sends 0.09: * Point>>@ * Compiled Object>>new * Fully integrated dynamic primitive inlining. Other likely items before 1.0: * A compiled ExuperyBlockContext>>value * Natively compiled String primitives (at least #at: and #at:put:) * Removal of SmallInteger tagging in expression trees. * Compiled inlined code to call Slang primitives 2.0 will probably just have full dynamically inlined messages. I'd really like have them as soon as possible because they will really change the costs of sends. I'd rather not do too much tuning of compiled sends until they are in place because hopefully most sends will be dynamically inlined. 3.0 is likely to have an SSA based optimiser. That should first provide another 2-4 times increase in bytecode performance then provide a good platform for further optimisations. The changes are I've slipped the Point>>@ and object creation work to 0.09 and full dynamically inlined messages to 2.0. This isn't really delaying either feature. Just focussing on improving the stability and usefulness of the entire system first. Dynamically inlined primitives are something that's been nearly fully working for a few releases now. They allow primitives to be inlined into a calling method which means that a primitive that's called frequently will be as fast as if it was implemented as a bytecode. Because they are dynamically inlined, they will be specialised for the actual types used by the sender. I've been using them for #at: and #at:put: in the bytecode benchmark. The only thing missing is finishing the type feedback mechanism. Bryce

1 0

Seaside and Exupery bug.
by Bryce Kampjes 26 Jan '06

26 Jan '06

Exupery and Seaside will not work together at the moment. The problem will occur if Exupery compiles a method that's then saved in a continuation, then Exupery's code cache is cleared, then the continuation is restored. Exupery's compiled contexts must be converted back into interpreted contexts before the code cache is cleared. The compiled contexts contain pointers into the code cache. Clearing the code cache without converting the contexts will lead to dangling pointers that should be to machine code. When the context is next entered it'll jump to machine code that's no longer there. Crash. The problem is Continuation>>initializeFromContext: uses instVarAt: and tempAt: to access the context's state. If Continuation called a serialisation method on the context which Exupery could implement sensibly then there wouldn't be a problem. I don't think compiled contexts should be stored in Seaside style continuations. The problem is the context and it's instance variables are stored separately and Exupery may need to convert the context to an interpreted context if it needs to clear out the compiled code. This problem is definitely easily fixable. Bryce

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Exupery