Exupery

exupery@lists.squeakfoundation.org

107 discussions

Asm-Generator - integration with Compiler
by sig 13 Jul '07

13 Jul '07

I plan to add integration with compiler/browser for assembler methods. The benefits is obvious: - prevent submitting valid smalltalk but invalid asm code - showing an error messages at point, where error is. - support for primitives. - automatic recompile-and-replace support To indicate that currently submitted method is assembler, developer just need to put <assembler> pragma in code. I will place some 'awful hacks' in Compiler to react on this pragma and redirect all further processing to my classes. By default, if no extra pragmas found, the code will be compiled by Exupery and registered as anonymous primitive, which will be invoked when interpreter enters this method. Additional pragmas can indicate a different calling conventions, or declaring a named primitive, which then can be used by other methods and other things yet to think of :) Also, putting a custom bytecode in compiled method, instead of one, which can be a result of parsing assembler code as smalltalk code can be more useful for error handling e.t.c. So, basically, an assembler methods will be a secret weapon to deal with anything which is speed crtitical (even comparing to Exupery compiled methods) and/or requires special processing, which available only at lowest levels - like interrupts, task switching, callbacks, native stack manipulation e.t.c. Currently, some of these areas can be covered only by plugins - forcing you to write slang/C code and be dependent on C compiler.

1 0

Asm-Generator with VMPointers plugin
by sig 11 Jul '07

11 Jul '07

Ok, this is the snapshot of my classes concerning asm-generator and VMPointers plugin. I prefer to see VMPointers in Exupery, because it provides something which is useful for Exupery and for my ASM-Generator - get pointers from VM executable :) Also, Bryce, see how i added a class into VMMaker. I think you can do same with Exupery and put all methods which changing VM to separate class (instead of Interpreter), and then just add it to list of classes needed to generate interp.c , as i did. This will make code much cleaner and separate your code from other :)

2 2

A minor issue with register allocator
by sig 03 Jul '07

03 Jul '07

I'm currently testing my asm-parser. And found it generates unneeded instruction (mov eax,eax): code of asm method: message4: arg1 with: arg2 | b c | self pragma: #cdecl. c := arg1 + arg2. b := arg1 / arg2. ^ c + b produced intermediate by parser: #(#(#block 1 #(#mov #(#add #(#argument #arg1) #(#argument #arg2)) #c) #(#mov #(#div #(#argument #arg1) #(#argument #arg2) 'temp7D6') #b) #(#return #(#add #c #b)))) then with transformed arguments and cdecl prologue/epilogue: #(#(#block 1 #(#push #ebp) #(#mov #esp #ebp)) #(#block 3 #(#mov #(#add #(#mem #(#add #ebp -4)) #(#mem #(#add #ebp -8))) 't1') #(#mov #(#div #(#mem #(#add #ebp -4)) #(#mem #(#add #ebp -8)) 't3') 't2') #(#mov #(#add 't1' 't2') #eax) #(#jmp #block2)) #(#block 2 #(#mov #ebp #esp) #(#pop #ebp) #(#ret))) and then i using LowLevelOptimiser ->InstructionSelector -> ColouringRegisterAllocator -> JumpRemover : #(#(#block 1 #(#push #ebp) #(#mov #esp #ebp)) #(#block 3 #(#mov #(-8 #ebp) #ebx) #(#add #(-4 #ebp) #ebx) #(#mov #(-4 #ebp) #eax) #(#mov #(-8 #ebp) #ecx) #(#cdq) #(#div #ecx) #(#mov #eax #eax) #(#add #ebx #eax)) #(#block 2 #(#mov #ebp #esp) #(#pop #ebp) #(#ret))) I suppose fix could be simple by testing in MedMov>>#visitWith: that if reg1 = reg2 then return nil , which will be interpreted as no-op by block. version used: Exupery-wbk.261.

2 8

Exupery Update
by bryce＠kampjes.demon.co.uk 03 Jul '07

03 Jul '07

Debugging continues, I've a very debuggable test now for the current bug. I'll try to hold off releasing until the background compiler can run for at least an hour however it's already much more reliable than any previous release. The problem is the quality bar has just gone up so old bugs are showing up. In some ways it would be sensible to release after the next bug is fixed regardless of how long the background compiler runs for as reliability has risen so much in this release already. It would be nice to release with the background compiler working well enough for people to play with it. Having a background compiler is a major milestone, it means that Exupery can be used for projects with very little user involvement. It would be a shame to release one bug before getting to tolerable reliability with the background compiler. I'll probably decide based on how hard it is to capture the next bug after this one is fixed whether to release. It is possible that the current bug is the last one that needs to be fixed to get it running for at least an hour. Progress will be slow until after ESUG as I've got two talks to write. Bryce

1 0

Re: Writing a primitive test first in Exupery
by Yakov Zaytsev 26 Jun '07

26 Jun '07

> Primitive code is implemented in IntermediateSimplifier which > converts high level intermediate into low level intermediate. Could some information about intermediates be provided? > Now look at IntermediateSimplifierTests>>testAtPrimitive. Use > this as an example to write a test for the "^ true" primitive. IntermediateSimplifierTests >>testAtPrimitive source := MedMethod createIntermediate: #((block 1 (primitive 60 Array block2 receiver arg1) )) for: machine. mockEmitter expectEmission: #((block1 (mov arg1 t1) "Index" (mov receiver t2) "receiver" (addressOfIndexedElement t2 t1 block2)) (block2)). ... It was discovered that createIntermediate:for: is connected with IntermediateCreator>>createBlock and friends... In order testTruePrimitive to be written, it's needed to be known how to write such arrays #((block 1 (primitive 60 Array block2 receiver arg1) )) Talking about MockIntermediateEmitter. Is this a pidgin assembler stateements (mov arg1 t1) "Index" (mov receiver t2) "receiver" (addressOfIndexedElement t2 t1 block2)) There's MockIntermediateEmitter>>addressOfIndexedElement:at:failTo: which probably is connected with (addressOfIndexedElement t2 t1 block2)) ..but there's no something similar to mov... It would be great if some more details will be given regarding how typical primitive test code is written Thanks in advance Yakov

2 3

Writing a primitive test first in Exupery
by bryce＠kampjes.demon.co.uk 18 Jun '07

18 Jun '07

Here's a quick sketch of what's needed to write a primitive test first in Exupery. This is aimed at getting Yakov started on his SummerTalk project but should also be useful to others who wish to write primitives for Exupery. Exupery is written test first using two layers of testing. First story tests are written to cover the functionality, they run compiled methods and check the compiled method does the right thing. Then programmer tests are written to cover the actual code. Ideally all new functionality is covered by both a full set of story tests and programmer tests. Primitive code is implemented in IntermediateSimplifier which converts high level intermediate into low level intermediate. I normally write the story tests first, often all the ones I can think of while reading through the interpreters implementation. Then I write the programmer tests one by one while implementing the code. I normally run the story tests to figure out what programmer test is needed next. First write a story test: ExuperyStoryTests>>testReturnTrue self compile: ' ^ true'. self should: [self example = true] This test will cover the case where the method is compiled directly, another test may be written to handle the inlined case for completeness. Now look at IntermediateSimplifierTests>>testAtPrimitive. Use this as an example to write a test for the "^ true" primitive. It should be possible to figure out what the primitive number is by debugging the failing testReturnTrue test. Browse around IntermediateEmitter to find out what facilities are there. In this case trueAddress and falseAddress look interesting. MockIntermediateEmitter is used during testing, it checks that the simplifier is producing the right intermediate and fails immediately if there's a problem. The aim is to write a test then write the code in the debugger produced from the failing test. Bryce

1 0

Introducing Huemul
by Guillermo Adrián Molina 26 May '07

26 May '07

I would be pleased if you could take a look at: http://www.guillermomolina.com.ar/huemul/index.php There you will find information to download a demo of the Smalltalk implementation that translates st code directly to assembler, using Exupery as the final compiler phase. Please let me know what you think. Regards, Guille

7 23

RE: Introducing Huemul
by Guillermo Adrián Molina 23 May '07

23 May '07

> > Guille, > > can this be used to take a normal squeak and transform it's image > into something that runs like huemul? > > cheers, > > Sebastian > > Well. Yes and no. If the question is, if someone would ever load a Squeak image in Huemul. the answer is no. Huemul will not have an image as we know it from normal smalltalks. When finished, Huemul will load modules (as normal C libraries) on demand. May be, one class per module. This modules and the small Huemul's executable, will persist all the objects seen by the system. On the other hand, Huemul *is* smalltalk, so, you may file in whatever you want. I am trying to make as little modifications as I can to the smalltalk code. Remember that the source of Huemul's classes is Squeak. May be you have a web application that runs over seaside. It would be possible that you could port your app without modifications at all to Huemul. Cheers Guille

1 0

Using my asm-generator with Exypery.
by sig 09 May '07

09 May '07

Hi everyone, i'm very interesting in Exupery progress, so i decided to join this list. If you may know i implemented a small parser, which translates a smalltalk source into asm instructions. (if you missed my post on squeak-dev, you can read it here: http://computeradvenrutes.blogspot.com/) I have read some threads in archive and come to conclusion, that Exupery itself can make a good use of my parser. Many primitives, which handle smallints/largeints can be coded in smalltalk and then translated using asm-parser to become low-level primitives. Then they can be placed in code cache as standalone functions, or what is more nicer - to be inlined by Exupery when compiling bytecodes of smalltalk methods! What is more important - it become easier to manage your low-level code, and keep all things in same place, without need of recompiling VM again and again. All what you need then is to compile source code of some class, get intermediate form of methods - and use these pieces of code for inlining when generating a method from bytecode, or put a near/far calls to it. Consider following example: you write the code: ------ PrimitiveSmallIntegers>>add: a with: b | result | self pragma: #inline. "tell the parser to not generate prologue/epilogue" " adding pair of smallintegers (assuming a and b is smallintegers!!) " ^ ( result := a + b ) ifNotOverflow: [ result - 1 ] else: [ self call: #coerceToBigIntsAndAdd:with: with: a with: b ] ------- and then in IntermediateGenerator>>generate:add: ^ self parsedMethod: #add:with: "return inlined form for adding two operands" It provides an easy way for extending Exupery with all basic numerics functionality (like big integers/floats), without jungles of hardly to write and hardly to manage mid-level code. Do you like my idea? -- regards sig.

3 6

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

07 May '07

Exupery 0.12 adds automatic profile driven background compilation. 0.13 should make it much more practical. All that's left to do for 0.12 is some bug fixing. The major problems I'm aware of are: * Compilation can be very slow, one method takes about 5 minutes to compile. * Many primitives are not compiled so code that relies on them will not be speed up. * Reliability. Reliability is improving but background compilation is demanding. There are two projects that it would be nice to add: * The closure compiler. I'd like to see a decent set of bytecodes added to allow closure code to be interpreted at the same speed as bytecodes. Compiling these new bytecodes should be relatively easy allowing decent compiled speed as well. * Generalizing primitive inlining to handle arithmetic operations. Arithmetic operations are inlined for SmallIntegers similar to the interpreter. This is fine but with type feedback we could inline for other types too. Currently, speeding up compilation looks like the best option for 0.13. Hopefully after the pre-release bug fixing 0.12 will be reliable enough to experiment with running in the background. I suspect that the bug that's most annoying when running the background compiler is caused by another bug introducing a fault in the compiler. Unfortunuately the register allocator is not fully deterministic so it's difficult to compare output from different runs to see if it changes. Being non-deterministic is not a correctness problem as often there are several equally valid choices but does make debugging potentual compiler bugs harder. Bryce

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Exupery