An unusual Performance approach using Synthetic registers, and a request for guidance.

[Andy Walker]

Thank you for your comments.

On Friday 27 December 2002 10:09 am, Michael S. Zick wrote:

<snip>

> Within the x86 instruction set, the "C" (%ECX) register may not be your
> best choice.
> Not because of compiler usage of the register, but because of uses
> of the register outside of the compiler (Hand coded __asm__ ).
> That is; hand coded __asm__, is hand coded to use ISA features that the
> compiler doesn't otherwise use.  Of those unused features, the %ECX
> register related special portions of the ISA are frequently used.

I agree that there is a great deal of hand coded assembler that uses the ecx 
register.  If I can figure out how, I will use the ebp register and make it 
do double duty.  

> A similar, but much weaker, argument could be made against using the
> %ESI and %EDI registers.

Registers esi and edi are used in gcc/i386 for loop control in memcpy.  If I 
use one of them for the Synthetic base register, I have to find another real 
general purpose register to use for memcopy.  

> The %EAX and %EDX registers are out of the question (the ISA single and
> double length result registers).

Yes.

> If you wanted to enforce the -fomit-frame-pointer option, the %EBP register
> has possibilities (if you also restrict yourself to stack/heap/data in the
> same address space).  But this path would probably be too restrictive for a
> general implementation.  

Why would this be too restrictive?

> Hmm... we seem to be running out of registers...

Yes.

<snip>
> So, I think (personal opinion here), using the %EBX register as the base
> (frame pointer) of the synthetic register frames should be your first
> choice.

It was.

> Think of it as generating code for a load/store ISA machine with the
> primary registers addressed %EBX relative.  This gives you two, double
> length, secondary registers (The %EAX/%EDX pair and the %ESI/%EDI pair)
> with a single length scratch register (%EAX).
> That is, you would be generating code for a 64bit (split) register size
> with coding for a 32bit register size the exceptional case.
> That allows you to combine your two register pairs to handle 128bit data
> as another exceptional case to the 64bit (split) register size coding;
> and a single 32bit scratch register (%ECX) that can be tested for zero with
> a single byte instruction.
>
> The argument I presented above is not 100% academic...
>
> I have actually done (in a non-compiler context) such x86 programming,
> with the added decoration of making the primary registers 10 bytes long
> so that they could hold any FPU/ALU data type.

Neat!

> That decision was driven by a desire to use the data-type conversion
> features of the FPU portion of the ISA as an intregal part of the synthetic
> machine.
>
> I should note that the above was done before the FPU learned to do
> vector instructions.  Which now might require a re-think of the old
> plan.
>
> Going beyond the register mapping I used departs too much from what
> you are planning to be of much use;
> But my register mapping from the synthetic machine to the real hardware
> was:
>
> Primary registers (frame): %EBX relative (a "zero address", stack machine,
> with the addition of directly addressable registers)
> First secondary register: %EAX/%EDX or FPU TOS(relative) as appropriate.
> Second secondary register: %ESI/%EDI or FPU TOS(relative) as appropriate.
> Scratch/Counter/Test for Zero register: %ECX
> I retained the ISA usage of the %EBP/%ESP register pair.
> I captured the FPU stack over-run, under-run exceptions to extend its
> hardware register stack into the synthetic (primary) registers (in my case,
> a stack rather than a fixed number of synthetic registers.

Interesting.  Given the x86 limitation of only doing fpu comparisons to 
stack-top values, I bet this was pretty efficient.

> Considering the FPU/ALU instruction set as a whole, I subset it to those
> instructions that worked directly on the actual hardware mappings.
>
> Mike