Exupery

exupery@lists.squeakfoundation.org

107 discussions

Some questions
by Guillermo Adrián Molina 06 May '07

06 May '07

Hi list, I been playing around with exupery. And now I have a few questions: 1) I cant get tinyBenchmarks working, neither in linux, nor in windows, Downloaded all the staff from: http://wiki.squeak.org/squeak/Installing+Exupery used: http://ftp.squeak.org/Exupery/vms/exupery-vm-0.11-linux.tz in linux and: http://ftp.squeak.org/Exupery/vms/exupery-vm-0.11-win32.zip in windows with prebuild image: http://ftp.squeak.org/Exupery/images/exupery-0.10.tz Examples run ok, but when I try to run tinyBenchmarks I get segmentation faults 2) Tried tinyBenchmarks in VisualWorks (NonCommercial 7.4.1) in my machine, I got: '652,229,299 bytecodes/sec; 89,016,165 sends/sec' Does anyone know Why I get almost 90 million sends/sec? I think It's quite a big difference from previous versions of vw 3) I saw that primitives for #at: and #at:put: are getting inlined, but I think they are only implemented for Variable Objects (not for bytes nor Characters nor anything else) Is that true? 4) In my experiments with exupery, I get an error if I inline too many methods. I think I am getting out of machine registers, for example, when I try to compile Integer-#digitDiv:reg:. I get this error In the ColouringRegisterAllocator phase, but it is not a "You dont have more registers, dude" kind of error. Is the "no more registers" situation taken into consideration? 5) Is there a way to implement indirect jump tables in exupery? Thanks a lot. Cheers Guille

3 14

Progress towards Exupery 0.12
by bryce＠kampjes.demon.co.uk 05 May '07

05 May '07

All that's required is a little more debugging. This release can compile in the background. The stress test runs again but when Exupery starts compiling itself using the background compiler after a few minutes it stops due to a bug. I'd like to be able to run the background compiler for at least an hour before releasing. Exupery is probably more reliable now than it's been before. The other part of this release has been fixing some old stack tracing bugs. That introduced block finder bugs which have been fixed along with some old block finder bugs. By the standards of previous releases, it would be releasable now. I'm thinking about freeing up the "unused" slot in MethodContext so that Exupery can be loaded in an image running the closure compiler without causing crashes. More work would be required to compile closure compiler code. Bryce

4 8

Exupery and the Closure Compiler
by bryce＠kampjes.demon.co.uk 29 Apr '07

29 Apr '07

Should Exupery 0.12 be made compatible with the closure compiler? Both Exupery and the closure compiler use the "unused" slot in MethodContext. Exupery uses the slot to indicate that the MethodContext uses native code. The closure compiler uses it to hold a pointer to the environment which contains shared variables. Exupery uses it because until recently Exupery used to use normal MethodContexts when executing compiled code. The native program counter was stored in the "unused" slot. If the slot was a SmallInteger it was the address to jump to to resume native code, if it was a nil then the context should be interpreted. When I added block support I moved the native program counter into the same slot as the interpreted program counter. Later ExuperyMethodContext was created to allow the debugger to work with compiled method contexts again. Originally they were the same to the debugger, but the "unused" slot should have been nilled out if the context was single stepped. With the native PC in the PC slot having a dedicated context object makes it easier to work with tools. Polymorphism can deal with converting the native program counter into a bytecode program counter and decompiling a context if it's changed through reflection. It's probably worthwhile me having a proper look at the logic to switch between native code and interpreted code. There was a bug that's been fixed in the Slang support (going from interpreted to compiled) and I'm not sure that the native code check has the same bug (going from compiled to interpreted). The bug was that interpreted blocks with a SmallInteger receiver were being treated as native code. I guess I should investigate before 0.12 even if I then decide not to change it. Are people interested in running Exupery and the closure compiler at the same time? Bryce

2 1

RE: Some questions
by Guillermo Adrián Molina 27 Apr '07

27 Apr '07

>> > Why do you need to build an indirect jump table? What are >> you trying >> > to do? >> > >> I am implementing a smalltalk. It compiles directly to >> machine code, with exupery. The last time I asked something >> to the list I was starting to use exupery. Now I am almost >> done with that (without many optimizations). I am doing unit >> testing right now. >> My first mail to the list asked what would be the best to >> implement a new st, so, in my implementation I use: >> 0 tagged ints. >> A simple (and a little fat) object memory. >> A very straightforward send mechanism (with C calling >> convention for calling methods). >> No contexts, but using BlockClosures (frames are the same as >> in C, the C compiler does not differentiate C code from ST code). > > Hi Guille, I don't get something here. If you are using Exupery to > generate > asm code why are you talking about a C compiler? > Hi Guille, I don't get something here. If you are using Exupery to generate asm code why are you talking about a C compiler? Ok, short answer: The ST VM is responsible for a lot of things, one of them is to interpret bytecodes. In my ST every method is stored in x86 machine code, so, I dont need any interpreter to interpret methods (the CPU does all that)., but VMs have to deal with a lot of other things, like primitives and method lookups. That part is done in C. Long answer: Right now building my VM is a little messy, this is more or less what I do: File out the classes I need from Squeak. Right now I use only ~50 basic classes, and ~40 test classes. The file out mechanism generates one file per class, called ClassName.st Compile methods in squeak I load every *.st file from squeak (I said load, not file in!). While I read the classes I compile the methods with SmaCC Refactory Browser - Exupery. This generates assembler as an intermediate step, but the final step produces x86 machine code. This is stored in every method. Generate assembler files from squeak Once everything is compiled I generate an assembler file for every class, for example ClassName.s. This could be a little confusing. I already compiled everything, why would I need to generate assembler files? Because assembler files are very handy to represent the image, take a look into a real method: /* Test>>test Method bytecodes */ .global Test_Class_test_bytecodes Test_Class_test_bytecodes: .int ByteArray + 1 .int 154 /* Number: 77 */ .int 17888 /* Number: 8944 */ .global _Test_Class_test_bytecodes _Test_Class_test_bytecodes: .byte 85, 137, 229, 139, 69, 8, 80, 184 .int Test_Class_test_literals + 1 .byte 139, 64, 11, 232 .int getMethodIP - 4 - . .byte 255, 208, 129, 196, 4, 0, 0, 0, 139, 69, 8, 80, 184 .int Test_Class_test_literals + 1 .byte 139, 64, 15, 232 .int getMethodIP - 4 - . .byte 255, 208, 129, 196, 4, 0, 0, 0, 80, 184 .int Test_Class_test_literals + 1 .byte 139, 64, 19, 232 .int getMethodIP - 4 - . .byte 255, 208, 129, 196, 4, 0, 0, 0, 201, 195 .align 2 As you can see, that is not assembler, but those bytes, are generated with Exupery. Notice the references to other Objects. It is very easy to represent the image with this method. For example, look how an array would be represented in this way: /* Array */ .global Test_Class_test_literals Test_Class_test_literals: .int Array + 1 .int 24 /* Number: 12 */ .int 9784 /* Number: 4892 */ .global _Test_Class_test_literals _Test_Class_test_literals: .int symbol_initialize + 1 .int symbol_selfTest + 1 .int symbol_printString + 1 Those + 1 , are there because of the 0 tagged integers. Generate a library with the code With all the .s files I generate a library Compile everything into a static executable I compile the library and the other C files into a static executable. I do that because right now, I havent implemented the st compiler. And thats why I still need squeak. When I implement the compiler (SmaCC-RB-Exupery), I will have to generate some kind of dynamic loading of the st part. Cheers Guille >> I compile the ST code from .st files to .s (assembler) using >> SmaCC, RefactoryBrowser, and then exupery, I still need >> squeak in order to run all that. >> I only use the bottom layer of exupery, (does not use >> IntermediateXXXXXX >> classes) >> I implemented the cmovxx instruction in exupery, because it >> is very useful. >> But I need jump tables to implement for example, faster >> versions of ifTrue:ifFalse:, and a lot of other things. This >> could lead to faster results. >> Right Now I am getting (with the same machine), tinyBenchmarks: >> Squeak: 172043010 bytecodes/sec; 5468700 sends/sec >> Squeak/Exupery: 775757575 bytecodes/sec; 13569800 sends/sec. >> myST/Exupery: 1072251308 bytecodes/sec; 36056442 sends/sec >> > That are numbers! > > Cheers, > > Sebastian > > >> > Bryce >> > _______________________________________________ >> > Exupery mailing list >> > Exupery(a)lists.squeakfoundation.org >> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery >> > >> Cheers >> Guille >> >> _______________________________________________ >> Exupery mailing list >> Exupery(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery > > _______________________________________________ > Exupery mailing list > Exupery(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery >

2 2

FW: Question about code generation
by bryce＠kampjes.demon.co.uk 12 Apr '07

12 Apr '07

J J writes: > Hello all, > > I sent this to the Exupery list, but no one answered. Maybe someone here > knows or has some pointers to where the information is Hi, I've been on holiday, just got back home last night. > >I was just curious how Exupery is able to directly generate the machine > >codes for a given platform. Squeak runs on a ton of platforms, so Exupery > >would have to have some way to know the codes for all of them. Exupery will need to be ported to each CPU. This does add to the effort to do a port to a new architecture but Exupery isn't required to run Squeak, it just makes it faster. > >I am curious because I was wondering about generation of the Squeak VM. > >Right now it is done with a smalltalk looking language called Slang (as you > >all know) that just converts directly to C. My thinking was the VM > >generator should at a minimum be a GCC front end and possibly build the > >executable itself (the problem with being a GCC front end is that it > >targets C, which may not be flexible enough). This might allow the VM to > >do some optimizations it can't at the moment (I seem to remember that C > >doesn't give you the information about float overflows, perhaps this might > >be useful to a language like smalltalk that doesn't make one pick the size > >of their numbers). Do you mean integer overflows rather than float overflows? Exupery currently uses the CPU flags to do cheap overflow checks for SmallIntegers. Floats are slow in Squeak because they're full objects, and I don't think they are overflow checked. There may be no performance gains from targeting GCC intermediate rather than C because the interpreter spends most of it's time recovering from branch mispredicts. There is spare cycles to do more real work while the pipeline refills afterwards. Moving to GCC intermediate would make portability harder, it is also a move from a well known and documented language (C) to an under documented language (GCC intermediate) which will reduce VM maintainability. > >I haven't looked far enough to see if this would be worthwhile, and I also > >wonder how such a change would play with Exupery. In a system with Exupery any gains to the interpreter will be less important because most of the time should be spent in compiled code not interpreted code. Interpreted performance will still matter for a few niche activities such as running Exupery's tests and starting an image. Bryce

1 0

Question about code generation
by J J 06 Apr '07

06 Apr '07

Hi list, I was just curious how Exupery is able to directly generate the machine codes for a given platform. Squeak runs on a ton of platforms, so Exupery would have to have some way to know the codes for all of them. I am curious because I was wondering about generation of the Squeak VM. Right now it is done with a smalltalk looking language called Slang (as you all know) that just converts directly to C. My thinking was the VM generator should at a minimum be a GCC front end and possibly build the executable itself (the problem with being a GCC front end is that it targets C, which may not be flexible enough). This might allow the VM to do some optimizations it can't at the moment (I seem to remember that C doesn't give you the information about float overflows, perhaps this might be useful to a language like smalltalk that doesn't make one pick the size of their numbers). I haven't looked far enough to see if this would be worthwhile, and I also wonder how such a change would play with Exupery. Thanks, Jason _________________________________________________________________ Cant afford to quit your job? Earn your AS, BS, or MS degree online in 1 year. http://www.classesusa.com/clickcount.cfm?id=866145&goto=http%3A%2F%2Fwww.cl…

1 0

Any volunteers to mentor a Crypto/Exupery Soc project?
by bryce＠kampjes.demon.co.uk 06 Mar '07

06 Mar '07

I've proposed a project to use Exupery to provide either fast ByteArray or fast 32 bit arithmetic aiming to be useful for cryptology. Is there any crypto people interested in co-mentoring? Most of the mentoring will be on the Exupery side but some help selecting benchmarks and evaluating the results could be very useful. The idea for 32 bit integers is to provide a proper boxed object that contains a 32 bit integer then write primitives for the required arithmetic. With some work (the project) Exupery should be able to remove the unnecessary boxing between expressions. If the objects were "register" objects that could be assigned to then there is a chance that we could remove all Smalltalk's overhead although a safe guess is would be we'd achieve about 1/2 C's speed. 32 bit integers are a great project because the code delivered could be very simply extended to also work with floating point numbers providing the same level of efficiency. Working with 32 bit integers allows the approach to be proven in a practical setting without also needing to add support for floating point instructions. Less work, but proves the same point and will be easily adaptable to do both. Bryce P.S. I messed up the exupery address in my first post thus I'm resending to the exupery list.

1 0

New implementation of squeak
by Guillermo Adrián Molina 04 Mar '07

04 Mar '07

Hi to all, I am a Smalltak VM enthusiast. I found this list an interesting reading. But I was wandering a few things. If you could rewrite the Squeak's object memory from scratch, in order to simplify and accelerate exupery, what would you do? -The first thing that come to my mind is SmallInts, Squeaks uses 1 tagged integers, but what would make your life easier? -What about floats?, would you tag them instead of boxing them? -Arrays,#at: and #at:put:, How would you implement arrays, in order to speed up #at: and #at:put: -bools? -The garbage collector, what solution is best suited for exupery? -sends and blocks?, what about them? Anything else? Thank you very much for your efforts of making exupery.

2 3

[ANN] Exupery 0.11 released
by bryce＠kampjes.demon.co.uk 02 Mar '07

02 Mar '07

This release contains: * primitives for #new and #@ * ExuperyMethodContext (allows full debugger support for compiled code) * interrupt checking (allows Alt-. and profiling to work inside compiled code) Installation instructions are here: http://wiki.squeak.org/squeak/3945 The new primitive only works for pointer objects with less than 64 instance variables and are a fixed size (not Arrays). This covers most uses inside Smalltalk, and the new primitive can be easily generalised when there's a benchmark that requires it. Here's the benchmarks: arithmaticLoopBenchmark 1387 compiled 127 ratio: 10.920 bytecodeBenchmark 2139 compiled 484 ratio: 4.419 sendBenchmark 1582 compiled 728 ratio: 2.173 doLoopsBenchmark 1063 compiled 843 ratio: 1.261 pointCreation 1075 compiled 1030 ratio: 1.044 largeExplorers 585 compiled 595 ratio: 0.983 compilerBenchmark 474 compiled 454 ratio: 1.044 Cumulative Time 1058.337 com We delayed this release to fix a bug found by Andy Tween that seems to occur frequently on Windows but is cross platform. Thank's to Andy's help the bug is now fixed. And thanks for building the Windows VMs. The next release will compile in the background. Bryce

3 2

Exupery 0.11rc1 is out
by bryce＠kampjes.demon.co.uk 02 Mar '07

02 Mar '07

I'm finishing up the 0.11 release. It should be both more reliable and more functional than 0.10. There are known bugs but they only stop methods from being compiled. They don't cause crashes or incorrect code. This release includes: * A #new and #@ primitive for fixed size pointer objects. * A class for compiled methods that provides better debugger support. * Interrupt checking from compiled code so Alt-. will work. This should include all the VM and compiler work required to allow methods to be compiled in the background safely. That's the goal for 0.12. I'm thinking about scripting building an Exupery development image. The development tools use GraphViz to layout the method's control flow graphs in inspectors. Also the tests can rely on external packages, this is normally when the test was created to capture a bug. I've had a look at Andrew's VM building script. It would be nice to automate the set-up of a VM building environment. Though, I'd rather have it scripted from Smalltalk than from shell. Would it be worthwhile adding the shell script to a class side method as executable documentation? It would be nice to have a Windows VM for this release. Bryce

3 4

← Newer
1
...
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