Some questions

[bryce at kampjes.demon.co.uk]

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