From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22182 invoked by alias); 1 Mar 2011 08:20:41 -0000 Received: (qmail 22170 invoked by uid 22791); 1 Mar 2011 08:20:40 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-iy0-f169.google.com (HELO mail-iy0-f169.google.com) (209.85.210.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Mar 2011 08:20:34 +0000 Received: by iyf13 with SMTP id 13so5016517iyf.0 for ; Tue, 01 Mar 2011 00:20:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.201 with SMTP id u9mr6298607ibu.61.1298967632471; Tue, 01 Mar 2011 00:20:32 -0800 (PST) Received: by 10.231.35.129 with HTTP; Tue, 1 Mar 2011 00:20:32 -0800 (PST) In-Reply-To: References: Date: Tue, 01 Mar 2011 08:20:00 -0000 Message-ID: Subject: Re: m68k fmovem From: kevin diggs To: Andreas Schwab Cc: binutils@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00000.txt.bz2 Hi, Adding some debug statements to tc-m68k.c reveals that (at least in 2.16.1) the statement: fmovem.l %fpcr,%d0 tries the operand pattern "IiL8~s" first (from m68k-opc.c). This fails to match because the '~' operand type does not include register direct. Unfortunately, the 'L' operand type changes the mode (opP->mode=REGLST) at line 1745. The operand pattern "Iis8%s" is tried next. This would have matched ... except the 's' operand type wants the mode to be CONTROL. But this got mucked up in the previous operand pattern check. If I comment out the losing++; at line 1817 then: unsigned int f(unsigned int *save) { unsigned int fpctrreg; asm volatile("fmovem.l %%fpcr,%0\n" :"=d"(fpctrreg) ); asm volatile("fmoveml %%fpcr/%%fpsr,%0@\n" : :"a"(save) ); return fpctrreg; } will assemble the first fmovem.l to 'f200 b000' which I think is correct (and also matches what a similar fmove produces). A quick check of the latest tc-m68k.c and m68k-opc.c (via cvsweb) would seem to indicate that this should issue should still exist (unless something has changed to alter the order that the operand patterns are tried). Any tips/pointers on how to fix this would be appreciated. Can we just change the order of the first two fmoveml patterns in m68k_op.c? Will that change the order that they are tried? I am a little afraid of trashing some other instruction. Thanks! kevin --- gas/config/tc-m68k-old_c Tue Mar 22 07:31:48 2005 +++ gas/config/tc-m68k-new_c Thu Dec 31 17:51:35 1903 @@ -1143,6 +1143,9 @@ return; } + fprintf(stderr,__FILE__"`%s()-%d: mnemonic=%s, opcode struct=%p, opcode=" + "%lx\n",__func__,__LINE__,instring,opcode,opcode->m_opcode); + /* Found a legitimate opcode, start matching operands. */ while (*p == ' ') ++p; @@ -1213,10 +1216,16 @@ ++losing; else { + fprintf(stderr,__FILE__"`%s()-%d: operand match string \"%s\"\n", + __func__,__LINE__,opcode->m_operands); + for (s = opcode->m_operands, opP = &the_ins.operands[0]; *s && !losing; s += 2, opP++) { + fprintf(stderr,__FILE__"`%s()-%d: matching operand %c%c\n", + __func__,__LINE__,*s,s[1]); + /* Warning: this switch is huge! */ /* I've tried to organize the cases into this order: non-alpha first, then alpha by letter. Lower-case @@ -1797,11 +1806,16 @@ break; case 's': + fprintf(stderr,__FILE__"`%s()-%d: mode=%d, CONTROL=%d, " + "reg=%d, FPI=%d/FPS=%d/FPC=%d\n", + __func__,__LINE__,opP->mode,CONTROL,opP->reg,FPI,FPS,FPC); + if (opP->mode != CONTROL || ! (opP->reg == FPI || opP->reg == FPS || opP->reg == FPC)) - losing++; +// losing++; + ; break; case 'S':