From: Andy Walker <ja_walker@earthlink.net>
To: Michael S. Zick <mszick@goquest.com>,
"GCC Developer's List" <gcc@gcc.gnu.org>
Subject: Re: An unusual Performance approach using Synthetic registers, and a request for guidance.
Date: Sun, 29 Dec 2002 02:18:00 -0000 [thread overview]
Message-ID: <E18SVS4-0003M5-00@falcon.mail.pas.earthlink.net> (raw)
In-Reply-To: <02122710093100.00766@localhost.localdomain>
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
next prev parent reply other threads:[~2002-12-29 4:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-27 5:04 Andy Walker
2002-12-27 10:55 ` Michael S. Zick
2002-12-27 11:44 ` Michael S. Zick
2002-12-28 4:58 ` Alexandre Oliva
2002-12-28 9:43 ` Michael S. Zick
2002-12-29 5:33 ` Andy Walker
2002-12-29 4:28 ` Andy Walker
2002-12-29 2:18 ` Andy Walker [this message]
2002-12-27 6:48 Bonzini
2002-12-27 20:07 ` Dave Hudson
2002-12-29 2:23 ` Andy Walker
2002-12-29 1:57 ` Andy Walker
2002-12-29 6:09 ` Bonzini
2002-12-29 12:04 ` Andy Walker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E18SVS4-0003M5-00@falcon.mail.pas.earthlink.net \
--to=ja_walker@earthlink.net \
--cc=gcc@gcc.gnu.org \
--cc=mszick@goquest.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).