public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tom Lord <lord@emf.net>
To: dewar@gnat.com
Cc: dewar@gnat.com, gcc@gcc.gnu.org, ja_walker@earthlink.net
Subject: Re: Sythetic registers: modrm/gas question.
Date: Mon, 06 Jan 2003 19:42:00 -0000	[thread overview]
Message-ID: <200301051351.FAA26401@emf.net> (raw)
In-Reply-To: <20030105131257.941B4F2D5D@nile.gnat.com> (dewar@gnat.com)



       It's a little more fundamental than that. It is central to the
       design of the x86 that the variable length offsets are
       optimized by the assembler.


Well, duh .... but synthregs are not about that.  It was a separate
question (unless ja_walker is a right-twice-a-day broken clock here).


        And that's the problem, It is being argued at too high a
        level, and creates the impression of some principle that in
        fact I do not believe will show up as improved code. You *DO*
        need to examine GCC's generated code to realize that the code
        we generate today is essentially equivalent to the idea of
        SR's.


It's _not_ equivalent.  Looking at just the instruction sequences and
ignoring cache considerations -- synthregs are almost certainly
slightly worse.

Synthregs improve locality at a slight cost in code size.  I agree
with ja_walker that the worthiness of that trade-off is an emprical
question worth measuring.  I'd go beyond him by saying that in the 
medium term future, the trade-off almost certainly wins often.


       Remember that the code you get for accessing a synthetic
       register is identical *in all respects* to the code you get for
       accessing local variables and arguments.

Great.  And synthregs can put _more_ of the values in a computation
into that access class.   



     The [stupid gas] question here seemed to imply that the
     fundamental idea behind the SR proposal was to take advantage of
     the 3-byte MODRM format for efficient access to SR's, coupled
     with a belief that GCC was using a 6-byte MODRM format for normal
     memory references. If that were true it would have some interest,
     but it is simply not true.


Nah, it doesn't imply that at all.  If _that_ were ja_walker's
concern, then instead of a synthreg proposal, he'd have made a
proposal to "fix gas" (making it what it already is).  Best available
evidence is that he isn't that clueless.


     You really HAVE to look at specific x86 assembly language
     sequences to see whether there is anything in this idea or
     not. Yes, there are some machines on which the idea might play
     out effectively, but I am pretyt convinced that the x86 is not
     one of them.

x86 is a "rapidly" exploding range of physical architectures.  I think
your statement is too sweeping, but I do get the impression you've
studied a subset of those physical architectures in excruciating
detail (hat's off).  (Please don't miss the point of the compliment
and reply that "Yeah, well, until you've done the same you've no
business talking about the SR proposal" --- that'll get (even more)
tiresome real quick, I promise. ;-)

-t

  parent reply	other threads:[~2003-01-06 19:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-05 13:25 Robert Dewar
2003-01-06  5:36 ` Andy Walker
2003-01-06 19:42 ` Tom Lord [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-01-07  3:13 Robert Dewar
2003-01-05 18:13 Robert Dewar
2003-01-05 20:15 ` Michael S. Zick
2003-01-05 14:24 Robert Dewar
2003-01-05 16:56 ` Michael S. Zick
2003-01-05 17:37   ` Michael S. Zick
2003-01-05 22:33 ` Tom Lord
2003-01-05 12:28 Robert Dewar
2003-01-06  5:04 ` Andy Walker
2003-01-06 19:47 ` Tom Lord
2003-01-05  6:08 Andy Walker
2003-01-06 23:54 ` Mike Stump
2003-01-07  6:15   ` 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=200301051351.FAA26401@emf.net \
    --to=lord@emf.net \
    --cc=dewar@gnat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=ja_walker@earthlink.net \
    /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).