m68k fmovem

m68k fmovem

[kevin diggs]

Hi,

While trying to rebuild gcc 3.4.6 on an old Mac Quadra 700 (68040), I
am getting:

floatformat.s: Assembler messages:
floatformat.s:1047: Error: operands mismatch -- statement `fmovem.l
%fpcr,%d5' ignored
floatformat.s:1163: Error: operands mismatch -- statement `fmovem.l
%fpcr,%d5' ignored

while trying to build floatformat.c from libiberty.

In the rebuild I switched to using binutils 2.16.1. I checked this
instruction in the M68000PRM.pdf and it seems to be legal? Anyone know
what I did wrong?

Thanks!

kevin

Re: m68k fmovem

[Andreas Schwab]

kevin diggs <diggskevin38@gmail.com> writes:

> While trying to rebuild gcc 3.4.6 on an old Mac Quadra 700 (68040), I
> am getting:
>
> floatformat.s: Assembler messages:
> floatformat.s:1047: Error: operands mismatch -- statement `fmovem.l
> %fpcr,%d5' ignored
> floatformat.s:1163: Error: operands mismatch -- statement `fmovem.l
> %fpcr,%d5' ignored
>
> while trying to build floatformat.c from libiberty.

Works fine here with binutils 2.21.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k fmovem

[kevin diggs]

Hi,

Thanks for taking the time to reply.

Either it worked in 2.11.2 or the code 'compiled' different and did
not use this instruction.

Any thoughts on whether 2.21 can be built on such an old release of NetBSD?

kevin

On Sun, Feb 27, 2011 at 12:48 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> kevin diggs <diggskevin38@gmail.com> writes:
>
>> While trying to rebuild gcc 3.4.6 on an old Mac Quadra 700 (68040), I
>> am getting:
>>
>> floatformat.s: Assembler messages:
>> floatformat.s:1047: Error: operands mismatch -- statement `fmovem.l
>> %fpcr,%d5' ignored
>> floatformat.s:1163: Error: operands mismatch -- statement `fmovem.l
>> %fpcr,%d5' ignored
>>
>> while trying to build floatformat.c from libiberty.
>
> Works fine here with binutils 2.21.
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>

Re: m68k fmovem

[kevin diggs]

Hi,

Or I would REALLY appreciate it if you could throw a few tips/pointers
my way on how gas works and where I might look to fix this in 2.16.1.

Thanks!

kevin

P.S.:  Andreas, based on your email addr, Is the video on this
supported very well yet? Like in color? And what about a Quadra 950.
Do we know how to use that IOP thing? I also have one of those Am29k
video cards? That usable? Thanks!

Re: m68k fmovem

[kevin diggs]

Hi,

Inside the 2.16.1 opcodes/m68k-opc.c I see:

/* FIXME: In the next instruction, we should only permit %dn if the
   target is a single register.  We should only permit %an if the
   target is a single %fpiar.  */
{"fmoveml", 4,  two(0xF000, 0x8000), two(0xF1C0, 0xE3FF), "Ii*lL8", mfloat },

What does this mean???

Thanks!

kevin

On Sun, Feb 27, 2011 at 1:55 PM, kevin diggs <diggskevin38@gmail.com> wrote:
> Hi,
>
> Or I would REALLY appreciate it if you could throw a few tips/pointers
> my way on how gas works and where I might look to fix this in 2.16.1.
>

Re: m68k fmovem

[kevin diggs]

Hi,

I was looking at the M68000PRM.pdf file and am ... confused. The
"fmovel fpcr,<ea>" on 5-80 (382) has the same encoding as the "fmoveml
<list>,<ea>" on 5-91 (393). Which is the preferred mnemonic to use?

kevin

On Sun, Feb 27, 2011 at 3:58 PM, kevin diggs <diggskevin38@gmail.com> wrote:
> Hi,
>
> Inside the 2.16.1 opcodes/m68k-opc.c I see:
>
> /* FIXME: In the next instruction, we should only permit %dn if the
>   target is a single register.  We should only permit %an if the
>   target is a single %fpiar.  */
> {"fmoveml", 4,  two(0xF000, 0x8000), two(0xF1C0, 0xE3FF), "Ii*lL8", mfloat },
>
> What does this mean???
>
> Thanks!
>
> kevin
>

Re: m68k fmovem

[kevin diggs]

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':