Some questions

Guillermo Adrián Molina guille at losmolina.com.ar
Mon Apr 30 05:19:27 UTC 2007


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

Ok, I will try to see what is happening. Is there any hard limit (besides
the number of available registers in x86 arch)?

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

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


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

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




More information about the Exupery mailing list