From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25824 invoked by alias); 13 Oct 2004 08:37:56 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 25795 invoked from network); 13 Oct 2004 08:37:54 -0000 Received: from unknown (HELO emea1-mh.id2.novell.com) (195.33.99.129) by sourceware.org with SMTP; 13 Oct 2004 08:37:54 -0000 Received: from EMEA1-MTA by emea1-mh.id2.novell.com with Novell_GroupWise; Wed, 13 Oct 2004 09:37:53 +0200 Message-Id: Date: Wed, 13 Oct 2004 08:37:00 -0000 From: "Jan Beulich" To: Subject: Re: i386 intel syntax integer load/store fp instructions Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2004-10/txt/msg00198.txt.bz2 Since the patch to remove the (superfluous) Intel syntax fildd, fistpd, and fisttpd instructions (24Jun2004) left intact the comments saying the next instruction would be Intel syntax, these comments now appear to apply to fildq, fistpq, and fisttpq respectively. Whether this is correct I cannot judge since I haven't been able to locate a formal AT&T syntax specification (in order to see whether these instructions actually exist there). With the pending Intel syntax patch (which replaces these instructions with suffix-less ones having the q_Suf attribute instead in order to accept true Intel syntax constructs using the 'qword ptr' operand modifier), these instructions wouldn't be accepted anymore in 32-bit AT&T mode (q_Suf is generally rejected in 32-bit mode), which may not be desirable (since gcc, for certain targets, still uses these). Any clarification on this would be appreciated, so that I could perhaps post a generally acceptable updated patch to address the various Intel syntax shortcomings. Thanks, Jan