Re: Gforth and gcc "progress"

Andrew Haley wrote:
I'm here. However, some of the problems you mention are already being
actively worked on and in any case are almost research-grade problems.
Vladimir Makarov has written various register allocators, and there
are rumours of a new one for gcc that might improve things.

One particular gripe I have with typical register allocators and the usage
pattern of registers in code like Gforth is that when such an allocator
fails at some point, the register ends up in memory all the time. That's
clearly not optimal. One comp.arch poster had a footer that said that most
performance problems resort to caching, and register allocation can be
treated just the same. Caching means that a variable that's loaded into a
register should live there as long as possible, but when no longer
possible, writing it to memory and later reloading it is perfectly ok. The
metric to minimize is the number of dynamic loads and stores. So if a value
sits in a register, and needs to be stored in memory for function calls
(caller-save), this is ok, as long as the function calls aren't more
frequent than accesses to the particular value.

This also helps for the x86 problem with its irregular register file - if
you find out that you need CX for an occasional shift operation, you then
still can use it for global values, which have to be pushed out just when
the shift operation needs CX (same for AX:DX for multiplications or
SI/DI/CX for string instructions).

There are a number of complications with this sort of split lifetime
register allocators, especially since debuggers have problems to localize
values when they change their position during the program flow. One interim
solution is to disable this sort of optimization when debugging.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
.

Relevant Pages

  • Re: Gforth and gcc "progress"
    ... register allocators, especially since debuggers have problems to ... lifetime register allocator, when I last proposed one (must be 10 years ... GCC's current allocator with such an allocator without giving up debugging. ... infinitely large) register file. ...
    (comp.lang.forth)
  • Re: Code density and performance?
    ... there are many simple ways to increase code density ... >> without seriously complicating implementation or impacting ... >> Coalescing register allocators can in most cases eliminate the ... That is, if set, the destination is the "next" register from the first ...
    (comp.arch)
  • Re: Code density and performance?
    ... >>> Coalescing register allocators can in most cases eliminate the ... allow only a small subset of the N^2 or N^3 possible pairs and triples ...
    (comp.arch)
  • Re: can somebody help me with the problem with tasm models
    ... When Intel created the x86 originally, ... registers...now, when addressing memory with something like "", this ... valid...the rest aren't yet wired in and are ignored in memory addressing ... "offset" register, this would give a 20-bit address...if, in time, they ...
    (alt.lang.asm)
  • Re: Calculating checksums...
    ... - it's a word memory reference using a register address ... lods - it's the lods instruction ... parens are a memory reference. ... programming and why, with the end of the 68k, teaching assembly ...
    (alt.lang.asm)