Some questions

[bryce at kampjes.demon.co.uk]

Guillermo Adrián Molina writes:
 > > 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.
 > >
 > 
 > Ok, I will try to see what is happening. Is there any hard limit (besides
 > the number of available registers in x86 arch)?

There should be no limit on the number of registers you can use. The
worst that should happen is you end up with a lot of spill code.

 > >  > 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.
 > >
 > Not right now, I will work on that later, When I have it I will send it to
 > you.

OK

 > > 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.
 > >
 > 
 > Intel's optimization manual says that cmov was introduced in Pentium, and
 > in AMD's optimization manual says that cmov is available from athlon. I
 > actually didn't investigate that thoroughly. The fact is that any modern
 > computer should have it. I know that in earlier implementations of cmov
 > (Pentium Pro) using the instruction wasn't really an advantage. But now,
 > it is really faster. My tinyBenchamrks showed a speed up of 10% when I
 > implemented cmov for smallinteger additions.
 > But, If you are really concerned about compatibility I think you should be
 > better considering not to use it.

I'm surprised that your SmallInteger addition code was helped. 

In Exupery the SmallInteger addtion sequence is
   bitTest arg1
   jumpIfSet failureBlock
   bitTest arg2
   jumpIfSet failureBlock
   clearTagBit arg1
   add arg1 arg2
   jumpOverflow failureBlock

The failure case is a full message send.

There are code fragments where cmov whould be helpful. Converting
to a boolean comes to mind. The part of "a > b" where you're loading
either true or false into the result register.

 > > Given adequate test coverage I'll add it.
 > 
 > I also implemented enter and leave instructions. Not because they were
 > better (they aren't), but, beacuse I use it to signal the inclusion of
 > additional prologue and epilogue code in a final phase added just after
 > the allocator. I do it that way because I dont know until then, which
 > registrs are used, and the number of additional temps needed. I know that
 > exupery allways push and pop all the registers (which aren't eax, edx and
 > ecx). And that it make place for a big context as temp space in stack. I
 > don't do that. I only push the used regs, and if that is not enough, I
 > enter additional stack space. That brakes compatibility with original
 > exupery, but I wanted to implement it that way. For small methods, that is
 > really better.
 > So, given that, I don't offer anything of this for you. I think you'll
 > understand.

Exupery's prolog and epilogue sequences could be improved. I've been
thinking about overhauling that area for a few years now. I'd like
to have variables spill into their actual locations. So if a stack
variable was stored, it would always be fetched from the context.
Then spilled registers wouldn't need to be loaded and stored on
context switches.

On thing that I might do in 0.13 is colour the isolated parts of a
method separately. That should improve register allocation as the
inteference graph will not be polluted by other isolated sections of
code. A compiled method is often made up of completely isolated
sections of code. Colouring the sections separately should also speed
up register allocation.

Bryce