From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8628 invoked by alias); 5 Jan 2003 22:14:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 8614 invoked from network); 5 Jan 2003 22:14:49 -0000 Received: from unknown (HELO emf.net) (205.149.0.20) by 209.249.29.67 with SMTP; 5 Jan 2003 22:14:49 -0000 Received: (from lord@localhost) by emf.net (K/K) id GAA28373; Sun, 5 Jan 2003 06:33:59 -0800 (PST) Date: Sun, 05 Jan 2003 22:33:00 -0000 From: Tom Lord Message-Id: <200301051433.GAA28373@emf.net> To: dewar@gnat.com CC: dewar@gnat.com, gcc@gcc.gnu.org, ja_walker@earthlink.net In-reply-to: <20030105141714.A8A65F2D5D@nile.gnat.com> (dewar@gnat.com) Subject: Re: Sythetic registers: modrm/gas question. References: <20030105141714.A8A65F2D5D@nile.gnat.com> X-SW-Source: 2003-01/txt/msg00236.txt.bz2 I disagree. In practice references to the local stack frame are nearly always in cache. Yeah, I see what you're saying (I think): Blindly tricking the register allocator isn't _quite_ right. It has to know not to bother storing locals and args in synthregs, and not to bother moving a spilled value to a synthreg. The thing I like about synthregs is the idea of moving some values not in those classes into locations that will be cache-favored. Just tricking the reg allocator seemed initially like an easy way to do it, but it's (hopefully only slightly) more complicated than that. > "Yeah, well, until you've done the same you've no > business talking about the SR proposal" Gosh, you took the words out of my mouth :-) :-) It's hard to articulate. I believe there's a perspective on architecture that transcends particular machines and that tends to predict the future pretty well. It's sort of like you look at the logical dependencies among various parts of the state of the abstract machine -- and those logical dependencies tell you a lot about how machines can be implemented and optimized (they are computations that have to be physically realized) -- and real machines tend sharply, over time, to take advantage of those optimizations. It's hard to articulate. It will take me a little while to digest the rest of your post. -t