Exupery October 2007

exupery@lists.squeakfoundation.org

4 participants
4 discussions

Exupery 0.12 release progress
by bryce＠kampjes.demon.co.uk 30 Oct '07

30 Oct '07

We've a Windows VM thanks to Andy. There's an Linux VM and a pre-built Exupery development image. There's also entries in SqueakMap and Package Universes. Links to the pre-build items are here: http://wiki.squeak.org/squeak/3945 The Package Universes Exupery Development package doesn't fully work. To use it load CommandShell from SqueakMap after loading it. This is because GraphViz needs the latest CommandShell which hasn't yet made it to universes. I've emailed Lex to get this sorted. Bryce

2 2

Preparing for Exupery 0.12
by bryce＠kampjes.demon.co.uk 27 Oct '07

27 Oct '07

I've decided to release what I've got. There's more than enough in this release to justify releasing. The background compiler now runs for about a hour. It'll still need some work before it is practical, that's probably next. This release * Has a background compiler that can be run for about a hour * Has many bug fixes * Merges in David and John's 32 bit clean work and makes Exupery 32 bit clean. Andy, when can you build a Window's VM? Mathieu is planning on building a Mac VM. To use the background compiler: First initialise Exupery to prepare the code cache. This will also clear out any currently compiled code. Exupery initialiseExupery Then start the background compiler using the following expression. Exupery startBackgroundCompilation. Then when done use the following to stop it. Exupery stopBackgroundCompilation. Bryce

2 2

Planning Exupery 0.13
by bryce＠kampjes.demon.co.uk 26 Oct '07

26 Oct '07

My current plan for 0.13 is: * Get background compiler to ignore methods that failed to compile * Don't flush the code cache on every class change * Fix more bugs * Add some instrumentation to get quantitative information on time spent compiling and the percentage of time spent in compiled code. The goal is to make the background compiler practical. It will still be limited due to missing features slowing down compiled code and slow compile times. A test would be to run the background compiler until Exupery was compiled then to start playing with tinyBenchmarks and to see the improvement as it compiles the methods and inlines the primitives. Currently the background compiler doesn't avoid methods that have failed to compile once. This is a problem as the compilation queue could get full of methods that don't compile blocking compilation of methods that do compile. Flushing the code cache on every class change is overkill. It also reduces the value of some of the acceptance testing as it can't effectively test compiling tests that change classes and several do. It would be nice if Exupery reported the percentage of time spent in compiled code to gauge how well the background compiler was doing. I can measure this using oprofile but not in Squeak. It would also be nice if Exupery recorded how long a method took to compile to gauge how much of a problem compilation speed currently is. It would be nice if Exupery recorded why methods failed to compile so it was easy to figure out how important adding the remaining missing features is. The other possibility for 0.13 would be to optimise compilation time. There are a few methods that take minutes to compile due to known performance bugs in the register allocator. Increasing the speed of the compiler will both make compilation more practical and make it cheaper to compile more code in tests. The third major thing required before a 1.0 would be to implement cascades and a few more bytecodes. This should allow Exupery to optimise more code successfully. This is aiming to optimise run time performance. I'm not considering this for 0.13 but is needed before 1.0. Bryce

2 2

Changing the names of all conditional branches
by bryce＠kampjes.demon.co.uk 07 Oct '07

07 Oct '07

I'm making Exupery 32 bit clean. This should help when running on OSes that like to place the image across the 2 Gig boundary or above it. As part of this I'm renaming the conditional jumps from names like jl, jle, and jg to jumpSignedLessThan, jumpSignedLessEqueals, and jumpSignedGreaterThan. This is so that it's easy to see what's using signed or unsigned comparisions. The 32 bit clean bugs are caused by using signed comparisions when the sign changes or is negative and we should be using unsigned comparisions. By renaming the conditional jumps it should be easy to keep such bugs out as it'll be easy to see what's signed or unsigned. Aso the longer names seem to make more sense when we're only occasionally dealing with that intermediate. The original names were taken from the x86 instruction set. Bryce

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Exupery October 2007