Exupery October 2008

exupery@lists.squeakfoundation.org

5 participants
7 discussions

native CompiledMethod format
by Gerardo Richarte 29 Oct '08

29 Oct '08

Hi, for some time I've been wondering how the native code for CompiledMethods is arranged, and I have a few specific questions. Any pointers to info will be very much welcome Are the native opcodes maintained in Smalltalk objects or in external memory? and then: Generally, how are CompiledMethods fixed after a Garbage Collection? for example, how are references to other objects handled? are calls to other methods somehow inlined (I mean, direct calls, not through lookups), and if so, how are this inlined direct calls solved when native code moves around (if it's stored in Object Memory) I know that by reading the code I can learn all this, but my need for info is not so serious :) thanks a lot! richie

2 1

( picoVerse-:( How do I get Exupery? ) )
by Kjell Godo 28 Oct '08

28 Oct '08

I tried http://mfrouter.dyndns.org/Exupery_VM.7z but nothing happened. I am making an assembler in Dolphin Smalltalk. It is trying to do all the addressing modes. It is part of the picoLARC project on SourceForge.net but the assembler stuff is not uploaded yet. It uses a Lispy syntax that looks like ( add ( into:From: EAX ( at ( + EBP 4 ) ) ) ) or ( add ( into:From: EAX ( at ( scale:index:base: 4 EBX EBP ) ) ) ) or ( push ( at EBP ) ) Doing it this way seems to minimize the compiling complexity. Plus it can participate in the picoLARC OOP macro system. Your Exupery way is more like regular assembler. It's brief and that's nice. But you also do long function names for machine language instructions which is good. All the addressing modes are mostly finished coding but untested. I would like to use Exupery to test against my picoLARC assembler. If possible.

3 11

That wasn't the bug
by bryce＠kampjes.demon.co.uk 09 Oct '08

09 Oct '08

Unfortunately the VM always marks the contexts before exuperyReturn is called, so the bug wasn't what I thought it was. Pity, that means I don't know what the remaining bugs are. Time for more testing. Bryce

1 0

[ANN] Exupery 0.14 is released
by bryce＠kampjes.demon.co.uk 06 Oct '08

06 Oct '08

The major improvement is to the speed of register allocation. I've fixed a couple of major performance problems so register allocation takes 50% of compilation time even for the largest methods. Register allocation now appears to take roughly linear time. There's still plenty of room to improve compilation time. Every stage copies the entire intermediate graph to produce the input to the next stage which is redundant, most stages only change a few places. The register allocator's liveness analyser still uses Sets to represent which variables are live rather than bit vectors. This release can compile cascades, the last missing core language feature. Exupery still can only compile a handful of the core primitives, it only compiles #at: for pointer objects. Cascades were added because they were used more in 3.10, the choice was either delete 2 system tests or add cascades. I delayed the release to add cascades. There's a few bug fixes of old bugs but this release is not noticeably more reliable than the previous release. It should be a bit more reliable though, especially when running the new Exupery VM. The new Exupery VM just has a single bug fix in it. Here's the benchmarks: arithmaticLoopBenchmark 414 compiled 94 ratio: 4.404 bytecodeBenchmark 726 compiled 264 ratio: 2.750 sendBenchmark 707 compiled 454 ratio: 1.557 doLoopsBenchmark 388 compiled 398 ratio: 0.975 pointCreation 433 compiled 423 ratio: 1.024 largeExplorers 257 compiled 258 ratio: 0.996 compilerBenchmark 248 compiled 249 ratio: 0.996 Cumulative Time 419 compiled 275 ratio 1.519 ExuperyBenchmarks>>arithmeticLoop 105ms SmallInteger>>benchmark 362ms InstructionStream>>interpretExtension:in:for: 6051ms Average 612.691 The key benchmark for this release is the last one, compiling interpretExtension:in:for: which now only takes 6 seconds. With previous version of the compiler it used to take over 2 minutes to compile. The change in times in the other benchmarks are mostly due to me upgrading from an Athlon 64 2.2GHz to a Core 2 3.0GHz. The register allocator should be slightly more efficient especially when compiling send heavy code. Reliability and compile time performance has dominated the last few releases. Now run time performance and reliability are the biggest issues. Exupery still can crash after about an hour's active use depending on what's being done. Bryce P.S. I don't think it'll be that useful to have VMs for all platforms. The old VM 0.12 should be fine for messing around. The new VM would be useful if anyone felt like trying to capture bugs though. If anyone want's to rebuild the VM for non-linux platforms, I'll delay announcing the release for a few days. I doubt it's worth the effort of re-creating a VM build environment though. I suspect that the major remaining bug has to do with de-compilation of contexts and may require VM changes to fix.

2 9

Exupery method cache
by Markus Fritsche 05 Oct '08

05 Oct '08

Hi, I just fired up an image where I compiled a few methods. When I start the image again, I can't compile because Exupery complains, that the plugin is missing. Is this how it's supposed to be or is there a bug in my vm-compilation/ image-compilation?

2 3

An update on progress
by bryce＠kampjes.demon.co.uk 05 Oct '08

05 Oct '08

The three things that have been added since the last release are: * More x86 addressing modes * Generic primitives (calling out to the interpreter's primitives) * Eliot's closure bytecodes and Freetype support merged into the VM More x86 addressing modes and generic primitives have helped out with performance. The addressing modes help out in send/return code which accesses VM variables. Previously the address of the variable had to be loaded into a register, then that used to access it. Now it can be done in a single instruction. Generic primitive support improves the number of cases Exupery can increase performance. If a primitive is called now that Exupery doesn't know how to compile, it can now dispatch to it via a PIC which is much faster than running through the interpreters lookup code. Eliot's closure bytecodes have been merged in because the Pharo developers would like to start using them. I'd like to see proper closure support. At the moment the VM will run closure code but Exupery will not be able to compile it. That will take another VM change, and an Exupery compiler change to free up the "unused" slot in MethodContext. The subpixel changes to bitblt have been merged into the VM, and the exupery-dev project on the Universes modified to load the packages required to build the FreeType plugin. I've got makefiles that work, they're not ideal but I ran into autoconf/automake issues that prevented using a better solution. Also, I think I know what one of the remaining bugs is. When returning into compiled code from interpreted code the compiled context is not being marked as a root. Contexts are real objects, and need to keep the garbage collector book-keeping. Any objects in old space must be marked as roots if they point to new space. To avoid write barrier checks on context writes (all stack operations, and temporary assignments), all contexts are marked as roots if they're in old space when they're entered. Exupery's code does the marking in the return bytecode because there are less returns than points to return to. Every send, or potential send has an entry point, which is much more than the number of return bytecodes. Next, I'll investigate this potential bug then fix it if it's real. Bryce

1 0

ExuperyPlugin?
by Markus Fritsche 05 Oct '08

05 Oct '08

Hello, I'm trying to build a win32 exupery vm - but there is no ExuperyPlugin in the monticello package. Is this intended?

3 13

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Exupery October 2008