From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27644 invoked by alias); 14 Jul 2006 17:03:44 -0000 Received: (qmail 27635 invoked by uid 22791); 14 Jul 2006 17:03:44 -0000 X-Spam-Check-By: sourceware.org Received: from mail.ardi.com (HELO pomo.griar.com) (69.49.166.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Jul 2006 17:03:41 +0000 Received: by pomo.griar.com (Postfix, from userid 5254) id 0CDCF8A4505; Fri, 14 Jul 2006 11:03:38 -0600 (MDT) To: binutils@sources.redhat.com Cc: Cliff Matthews Subject: Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands In-Reply-To: <20050506192411.GA22563@redhat.com> References: From: ctm@ardi.com (Clifford T. Matthews) Date: Fri, 14 Jul 2006 17:03:00 -0000 Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00185.txt.bz2 Howdy, I'm a little over a year late to the discussion, but it was only yesterday that I figured out that I was being bitten by a change that was made in May of 2005. Syn68k is software (written by Mat Hostetter) that dynamically translates 68k assembly to x86 assembly. It doesn't want to invoke a full-blown assembler as it does its work, so instead, at build time, it uses gas to compile a whole bunch of templates and figure out the significance of the bits that get created. Starting with binutils-2.16.90.0.3, instructions like lea 0x0(%eax),%eax began compiling into the exact same byte sequence as lea (%eax),%eax That change broke Syn68k, because it observed that the byte sequence for a zero displacement was significantly different from the rest (two bytes versus three bytes). In theory, Syn68k should have been able to construct translation code that understood the difference. In reality, it created code that didn't work. Oops. I "fixed" Syn68k by putting in special-case code that tells it to ignore the templates that have 0 displacements. That happens to work for our current template set. A better fix would be to fix the pattern matching code to be able to deal with this new change, but there's not sufficient use of Syn68k to justify the effort. An alternative fix would be to use whatever syntax (or command line switch) gas would take to allow Syn68k to tell gas that it really does want a zero displacement rather than no displacement. However, AFAICT, there no longer is such a syntax, nor is there a command line option to suppress the elision. I do exceedingly small amounts of assembly work these days and when things don't go my way, I can still hack tools that I have the source for (well... actually I can hack tools that I don't have the source for, but that takes even longer). As such, the lack of syntax or a command line switch to request a zero displacement doesn't really matter to me, but on May 6th 2005, DaveK wrote: "Nothing the user _explicitly_ specifies should ever be discarded IMO. What if someone wants to write self-modifying code that stores varying offsets into that field?" I largely agree with that sentiment, but with 20/20 hindsight and standing on his shoulders, perhaps I'd say Removing a way for a user to explicitly request something is bad. What if someone wants what he requested for some reason that we haven't anticipated? Either way, my experience might be an interesting data point for some of you. -- Cliff Matthews