Some questions

[Guillermo Adrián Molina]

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

_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Bryce Kampjes]

Guillermo Adrián Molina writes:
 > 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

Try using the 0.11 Exupery VM with Exupery 0.11. Exupery VMs must
match the Exupery version. The interface between Exupery and the VM is
still evolving.

 > 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?

It's true. #at: and #at:put: are only implemented for variable
objects. I should write primitives for other types. Good benchmarks
that demonstrate the need for such primitives would be nice.

 > 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?

I'd guess that it was because a variable was live at an entry point.
There's a stack tracing bug which I'm just fixing that could have
caused that.

I use the liveness analyser in the register allocator to catch
compiler bugs. It's much nicer to catch them there than with crashes.

 > 5) Is there a way to implement indirect jump tables in exupery?

It would be possible. I do use indirect jumps for returns to compiled
methods. If you look at any method you should see at least one
indirect jump in the return code. Just jump to a register.

Bryce
_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Guillermo Adrián Molina]

Hi there!
Thanks for the answers, found them very useful
I have a few more questions

> Guillermo Adrián Molina writes:
>  > 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
>
> Try using the 0.11 Exupery VM with Exupery 0.11. Exupery VMs must
> match the Exupery version. The interface between Exupery and the VM is
> still evolving.
>

Ok!, tried that, it worked:
668407310 bytecodes/sec; 13559830 sends/sec
760772659 bytecodes/sec; 13803237 sends/sec
777524677 bytecodes/sec; 12762744 sends/sec
760772659 bytecodes/sec; 13834279 sends/sec
775757575 bytecodes/sec; 13569800 sends/sec
I read something about intel being faster than AMD for exupery, Do you
know why is that?

>  > 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?
>
> It's true. #at: and #at:put: are only implemented for variable
> objects. I should write primitives for other types. Good benchmarks
> that demonstrate the need for such primitives would be nice.
>

I 'll try to check that, thanks

>  > 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?
>
> I'd guess that it was because a variable was live at an entry point.
> There's a stack tracing bug which I'm just fixing that could have
> caused that.
>
> I use the liveness analyser in the register allocator to catch
> compiler bugs. It's much nicer to catch them there than with crashes.
>

Yes I've seen those kind of errors (variable live at entry point),
corrected them initializing temps with nil.
I think this is something different. In this method of the
ColouringRegisterAllocator:

findNodeToSpill
        | spillable |
        "This is just a basic heuristic, spill the register that interferes with
the most
        other registers. It is possible to do a lot better.
        The heuristic should concider how much each register is used while it is
alive"
        spillable := spillWorklist select:
                [:each | ((self hasSpill: each register) not) and: [each register
isMachineRegister not]].
        spillable := spillable asSortedCollection: [:a :b| a spillWeight > b
spillWeight].
        ^ spillable first

After compiling lots of methods using exupery, it fails with very big
methods because spillable is nil, and spillable first throws an error. If
I make less inlining (for example, not inlining divisions and
multiplications), it compiles ok!
Any ideas?

>  > 5) Is there a way to implement indirect jump tables in exupery?
>
> It would be possible. I do use indirect jumps for returns to compiled
> methods. If you look at any method you should see at least one
> indirect jump in the return code. Just jump to a register.
>
Yes, I checked that, but I still need to initialize that register with the
convenient block, but I need to do that without using Jcc (conditional
jumps) to choose from the right one, Any suggestions?


> Bryce
> _______________________________________________
> Exupery mailing list
> Exupery@...
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>

Thanks a lot
cheers, Guille

_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Bryce Kampjes]

Guillermo Adrián Molina writes:

 > Ok!, tried that, it worked:
 > 668407310 bytecodes/sec; 13559830 sends/sec
 > 760772659 bytecodes/sec; 13803237 sends/sec
 > 777524677 bytecodes/sec; 12762744 sends/sec
 > 760772659 bytecodes/sec; 13834279 sends/sec
 > 775757575 bytecodes/sec; 13569800 sends/sec
 > I read something about intel being faster than AMD for exupery, Do you
 > know why is that?
 >

Exupery was much faster than the interpreter on Pentium 4s. That's
because the Pentium 4 is an inefficient chip to run the interprter on.

Those comparisions are rather old now. Hardware has moved on and so
has Exupery. Benchmarking now with bigger suites may show different
numbers.

 > >  > 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?
 > >
 > > I'd guess that it was because a variable was live at an entry point.
 > > There's a stack tracing bug which I'm just fixing that could have
 > > caused that.
 > >
 > > I use the liveness analyser in the register allocator to catch
 > > compiler bugs. It's much nicer to catch them there than with crashes.
 > >
 >
 > Yes I've seen those kind of errors (variable live at entry point),
 > corrected them initializing temps with nil.
 > I think this is something different. In this method of the
 > ColouringRegisterAllocator:
 >
 > findNodeToSpill
 > | spillable |
 > "This is just a basic heuristic, spill the register that interferes with
 > the most
 > other registers. It is possible to do a lot better.
 > The heuristic should concider how much each register is used while it is
 > alive"
 > spillable := spillWorklist select:
 > [:each | ((self hasSpill: each register) not) and: [each register
 > isMachineRegister not]].
 > spillable := spillable asSortedCollection: [:a :b| a spillWeight > b
 > spillWeight].
 > ^ spillable first
 >
 > After compiling lots of methods using exupery, it fails with very big
 > methods because spillable is nil, and spillable first throws an error. If
 > I make less inlining (for example, not inlining divisions and
 > multiplications), it compiles ok!
 > Any ideas?

I'd guess it's a limit with the register allocator. It is possible
that it can fail to find a register to spill when it needs to spill
something. Given this bug will not cause crashes or incorrect
execution it's not high priority.

 > >  > 5) Is there a way to implement indirect jump tables in exupery?
 > >
 > > It would be possible. I do use indirect jumps for returns to compiled
 > > methods. If you look at any method you should see at least one
 > > indirect jump in the return code. Just jump to a register.
 > >
 > Yes, I checked that, but I still need to initialize that register with the
 > convenient block, but I need to do that without using Jcc (conditional
 > jumps) to choose from the right one, Any suggestions?

Exupery also can get the address of a block. That's also done in the
send code to save the compiled program counter. The compiled program
counter is the address of the machine code block to return to encoded
as a SmallInteger. Return blocks are aligned to 2 byte boundaries to
allow for tagging. That's enough to build an indirect jump table if
you wanted to do that.

Why do you need to build an indirect jump table? What are you trying
to do?

Bryce
_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Guillermo Adrián Molina]

> Guillermo Adrián Molina writes:
>
>  > Ok!, tried that, it worked:
>  > 668407310 bytecodes/sec; 13559830 sends/sec
>  > 760772659 bytecodes/sec; 13803237 sends/sec
>  > 777524677 bytecodes/sec; 12762744 sends/sec
>  > 760772659 bytecodes/sec; 13834279 sends/sec
>  > 775757575 bytecodes/sec; 13569800 sends/sec
>  > I read something about intel being faster than AMD for exupery, Do you
>  > know why is that?
>  >
>
> Exupery was much faster than the interpreter on Pentium 4s. That's
> because the Pentium 4 is an inefficient chip to run the interprter on.
>
> Those comparisions are rather old now. Hardware has moved on and so
> has Exupery. Benchmarking now with bigger suites may show different
> numbers.
>
>  > >  > 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?
>  > >
>  > > I'd guess that it was because a variable was live at an entry point.
>  > > There's a stack tracing bug which I'm just fixing that could have
>  > > caused that.
>  > >
>  > > I use the liveness analyser in the register allocator to catch
>  > > compiler bugs. It's much nicer to catch them there than with crashes.
>  > >
>  >
>  > Yes I've seen those kind of errors (variable live at entry point),
>  > corrected them initializing temps with nil.
>  > I think this is something different. In this method of the
>  > ColouringRegisterAllocator:
>  >
>  > findNodeToSpill
>  > | spillable |
>  > "This is just a basic heuristic, spill the register that interferes
> with
>  > the most
>  > other registers. It is possible to do a lot better.
>  > The heuristic should concider how much each register is used while it
> is
>  > alive"
>  > spillable := spillWorklist select:
>  > [:each | ((self hasSpill: each register) not) and: [each register
>  > isMachineRegister not]].
>  > spillable := spillable asSortedCollection: [:a :b| a spillWeight > b
>  > spillWeight].
>  > ^ spillable first
>  >
>  > After compiling lots of methods using exupery, it fails with very big
>  > methods because spillable is nil, and spillable first throws an error.
> If
>  > I make less inlining (for example, not inlining divisions and
>  > multiplications), it compiles ok!
>  > Any ideas?
>
> I'd guess it's a limit with the register allocator. It is possible
> that it can fail to find a register to spill when it needs to spill
> something. Given this bug will not cause crashes or incorrect
> execution it's not high priority.
>
>  > >  > 5) Is there a way to implement indirect jump tables in exupery?
>  > >
>  > > It would be possible. I do use indirect jumps for returns to compiled
>  > > methods. If you look at any method you should see at least one
>  > > indirect jump in the return code. Just jump to a register.
>  > >
>  > Yes, I checked that, but I still need to initialize that register with
> the
>  > convenient block, but I need to do that without using Jcc (conditional
>  > jumps) to choose from the right one, Any suggestions?
>
> Exupery also can get the address of a block. That's also done in the
> send code to save the compiled program counter. The compiled program
> counter is the address of the machine code block to return to encoded
> as a SmallInteger. Return blocks are aligned to 2 byte boundaries to
> allow for tagging. That's enough to build an indirect jump table if
> you wanted to do that.
>

Yes I also notice that, using MedAddress, right?
Forgive me, but I still can't get the point:
For example:

MedMov
        from: (MedAddress addressOf: blockN)
        to: aMedReg
MedJump
        type: #jmp
        target: aMedReg
block1:
do something1
jmp end
block2:
do something2
jmp end
block3:
do something3
end:

this could be a jump table,
But I still need to select which block to jmp.
The only way of selecting the block I can Imagine is nesting compares,
something with jumps like:
MedJump
        type: #jc
        target: aLabel
        instruction: (MedComparision
                operator: #bitTest
                arg1: aMed
                arg2: (MedLiteral literal: 0))).
But I want to implement a jump table to avoid conditional branching

> 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).
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

> Bryce
> _______________________________________________
> Exupery mailing list
> Exupery@...
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>
Cheers
Guille

_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Sebastian Sastre-2]

> > 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?

> 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@...
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
> >
> Cheers
> Guille
>
> _______________________________________________
> Exupery mailing list
> Exupery@...
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Guillermo Adrián Molina]

>> > 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
don’t need any interpreter to interpret methods (the CPU does all that).,
but VM’s 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 haven’t implemented the st compiler. And that’s
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@...
>> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>> >
>> Cheers
>> Guille
>>
>> _______________________________________________
>> Exupery mailing list
>> Exupery@...
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>
> _______________________________________________
> Exupery mailing list
> Exupery@...
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>

_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Bryce Kampjes]

Guillermo Adrián Molina writes:
 > > Exupery also can get the address of a block. That's also done in the
 > > send code to save the compiled program counter. The compiled program
 > > counter is the address of the machine code block to return to encoded
 > > as a SmallInteger. Return blocks are aligned to 2 byte boundaries to
 > > allow for tagging. That's enough to build an indirect jump table if
 > > you wanted to do that.
 > >
 > Yes I also notice that, using MedAddress, right?
 > Forgive me, but I still can't get the point:
 > For example:

MedAddress is a literal that represents the address of a block. In
Exupery it gets relocated to be the blocks actual address.

You could write now:
    (jmp (mem (add (MedAddress blockWithTable) (sar anIndex 2))))

The only thing missing is a way to produce a block that just contained
literals. In your case a block that contained MedAddresses.

The MedAddress should be translated into a label refering to the
block.

Exupery currently does not have blocks that contain literals but
it shouldn't be too hard to add.

 > 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.

Interesting, what is the goal of your new Smalltalk? What are you
trying to do better than the other dialects or is this purely for
enjoyment?

Bryce
_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Bryce Kampjes]

Guillermo Adrián Molina writes:
 > 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

The first versions of Exupery generated gas assembly which
I compiled then linked against C support code. Even after
Exupery could compile inline I kept the code around to generate
assembly instructions for several releases. It eventually got
deleted as it wasn't adding any value.

If you're planning on continuing generating assembly then it
might be worthwhile to try and find the code to produce assembly and
update it to deal with the current instruction selector and the
instructions that have been added since I stopped maintaining it.

Bryce
_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Guillermo Adrián Molina]

> Guillermo Adrián Molina writes:
>  > 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
>
> The first versions of Exupery generated gas assembly which
> I compiled then linked against C support code. Even after
> Exupery could compile inline I kept the code around to generate
> assembly instructions for several releases. It eventually got
> deleted as it wasn't adding any value.
>
> If you're planning on continuing generating assembly then it
> might be worthwhile to try and find the code to produce assembly and
> update it to deal with the current instruction selector and the
> instructions that have been added since I stopped maintaining it.
>

Well, it is good to know that, but I need to generate machine code, not
assembler code. I am generating assembler files just to make it easier to
mantain the relationship between objects. As you can see from the code,
the C compiler doesn't know (at compile time) what are those bytes. Before
I used exupery, I was generating assembler, but thanks to exupery, that
step isn't necessary.
In the future I am planning to generate some kind of relocatable objects
(instead of assembler files), that could be loaded on demand at run time.

Cheers, Guille
> Bryce
> _______________________________________________
> Exupery mailing list
> Exupery@...
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>


_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Bryce Kampjes]

Guillermo Adrián Molina writes:
 > >  > After compiling lots of methods using exupery, it fails with very big
 > >  > methods because spillable is nil, and spillable first throws an error.
 > > If
 > >  > I make less inlining (for example, not inlining divisions and
 > >  > multiplications), it compiles ok!
 > >  > Any ideas?
 > >
 > > I'd guess it's a limit with the register allocator. It is possible
 > > that it can fail to find a register to spill when it needs to spill
 > > something. Given this bug will not cause crashes or incorrect
 > > execution it's not high priority.

If you want to fix that limit in the register allocator I could give
you some pointers. The problem is due to to how the problem is broken
down into stages. I'd need to dig through code to remember the details
though.

I'm planning on working on the register allocator in the next release.
The goal will be making it faster, it has a few serious performance
problems.

Bryce
_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Guillermo Adrián Molina]

> Guillermo Adrián Molina writes:
>  > >  > After compiling lots of methods using exupery, it fails with very
> big
>  > >  > methods because spillable is nil, and spillable first throws an
> error.
>  > > If
>  > >  > I make less inlining (for example, not inlining divisions and
>  > >  > multiplications), it compiles ok!
>  > >  > Any ideas?
>  > >
>  > > I'd guess it's a limit with the register allocator. It is possible
>  > > that it can fail to find a register to spill when it needs to spill
>  > > something. Given this bug will not cause crashes or incorrect
>  > > execution it's not high priority.
>
> If you want to fix that limit in the register allocator I could give
> you some pointers. The problem is due to to how the problem is broken
> down into stages. I'd need to dig through code to remember the details
> though.
>

Yes I do want. Please let me know where to start.

> I'm planning on working on the register allocator in the next release.
> The goal will be making it faster, it has a few serious performance
> problems.
>
Exupery's compile time is not a problem for me. But may be I have to wait
for you to finish with the register allocator, in order to try to fix the
limit.
Please let me know what do you want me to do.
Right now, I have allready finished with unit testing. The next thing I
will do is to include all the compiler classes in my project (remeber that
right now, that is done in Squeak), may be it would be convenient for me
to wait for 0.12 before I do that.

Another thing, Do you want the code I made for cmovxx?

Cheers Guille.


> Bryce
> _______________________________________________
> Exupery mailing list
> Exupery@...
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>


_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Bryce Kampjes]

Guillermo Adrián Molina writes:
 > > If you want to fix that limit in the register allocator I could give
 > > you some pointers. The problem is due to to how the problem is broken
 > > down into stages. I'd need to dig through code to remember the details
 > > though.
 > >
 > Yes I do want. Please let me know where to start.

If it's not an urgent problem then it may be better to wait
until after 0.13. Or to look at the register allocator during
0.13 development.

Have a look at the stages of simplification. They're done

ColouringRegisterAllocator>>processWorkLists
        simplifyWorklist isEmpty ifFalse: [^ self simplify].
        self coalesce ifTrue: [^ self].
        self freeze ifTrue: [^ self].
        spillWorklist isEmpty ifFalse: [^ self spillRegister].
        self spillMove

Sets the steps for processing. However the spill worklist has some
registers on it that shouldn't be spilled, so it tries to select a
register to spill. It discards all registers then fails.

I'd see if there are any moves that might be spilled afterwards,
if so, then all you'd need to do is allow spillRegister to fail
gracefully.

 > > I'm planning on working on the register allocator in the next release.
 > > The goal will be making it faster, it has a few serious performance
 > > problems.
 > >
 > Exupery's compile time is not a problem for me. But may be I have to wait
 > for you to finish with the register allocator, in order to try to fix the
 > limit.
 > Please let me know what do you want me to do.
 > Right now, I have allready finished with unit testing. The next thing I
 > will do is to include all the compiler classes in my project (remeber tat
 > right now, that is done in Squeak), may be it would be convenient for me
 > to wait for 0.12 before I do that.
 >
 > Another thing, Do you want the code I made for cmovxx?

I'm interested.

Does it have unit test coverage? Exupery development relies on
testing so that's required.

When was cmov introduced? I know it was a long time ago but can't
remember precisely when. What I'm concerned with is making Exupery
incompatable with some chips that might still be being used.

Given adequate test coverage I'll add it.

Bryce
_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

[Guillermo Adrián Molina]

> Guillermo Adrián Molina writes:
>