Coldfire uC5282 Question
Eric Norum
WENorum at lbl.gov
Tue Mar 30 23:06:30 UTC 2010
Multilib version 5208 sounds right. It should have the same CPU32 core as the 5282, or a least pretty close. For sure the 5208 won't have DBCC, either.
I tried the following little C program:
#include <string.h>
char *cp;
main()
{
memset (cp, 5, 100);
return 0;
}
And compiled it with: m68k-rtems4.10-gcc -mcpu=5282 -v -O4 m.c
The link edit stage was:
/usr/local/rtems/rtems-4.10/libexec/gcc/m68k-rtems4.10/4.4.2/collect2 /usr/local/rtems/rtems-4.10/lib/gcc/m68k-rtems4.10/4.4.2/../../../../m68k-rtems4.10/lib/m5208/crt0.o -L/usr/local/rtems/rtems-4.10/lib/gcc/m68k-rtems4.10/4.4.2/m5208 -L/usr/local/rtems/rtems-4.10/lib/gcc/m68k-rtems4.10/4.4.2/../../../../m68k-rtems4.10/lib/m5208 -L/usr/local/rtems/rtems-4.10/lib/gcc/m68k-rtems4.10/4.4.2 -L/usr/local/rtems/rtems-4.10/lib/gcc/m68k-rtems4.10/4.4.2/../../../../m68k-rtems4.10/lib /var/folders/B3/B3Xa8pTJEEm4plqQBpCki++++TU/-Tmp-//ccqTTObt.o -lgcc -lc -lgcc
A gdb disassem reveals:
(gdb) disassem memset
Dump of assembler code for function memset:
0x80000490 <memset+0>: moveal %sp@(4),%a0
0x80000494 <memset+4>: movel %sp@(8),%d0
0x80000498 <memset+8>: movel %sp@(12),%d1
0x8000049c <memset+12>: cmpil #16,%d1
0x800004a2 <memset+18>: bcsw 0x800004f0 <memset+96>
0x800004a6 <memset+22>: movel %d2,%sp at -
0x800004a8 <memset+24>: moveb %d0,%d2
0x800004aa <memset+26>: lsll #8,%d0
0x800004ac <memset+28>: moveb %d2,%d0
0x800004ae <memset+30>: movew %d0,%d2
0x800004b0 <memset+32>: swap %d0
0x800004b2 <memset+34>: movew %d2,%d0
0x800004b4 <memset+36>: movel %a0,%d2
0x800004b6 <memset+38>: negl %d2
0x800004b8 <memset+40>: andil #3,%d2
0x800004be <memset+46>: beqw 0x800004d4 <memset+68>
0x800004c2 <memset+50>: subl %d2,%d1
0x800004c4 <memset+52>: lsrl #1,%d2
0x800004c6 <memset+54>: bccw 0x800004cc <memset+60>
0x800004ca <memset+58>: moveb %d0,%a0 at +
0x800004cc <memset+60>: lsrl #1,%d2
0x800004ce <memset+62>: bccw 0x800004d4 <memset+68>
0x800004d2 <memset+66>: movew %d0,%a0 at +
0x800004d4 <memset+68>: movel %d1,%d2
0x800004d6 <memset+70>: lsrl #2,%d2
0x800004d8 <memset+72>: subql #1,%d2
0x800004da <memset+74>: movel %d0,%a0 at +
0x800004dc <memset+76>: subql #1,%d2
0x800004de <memset+78>: bplw 0x800004da <memset+74>
0x800004e2 <memset+82>: andil #3,%d1
0x800004e8 <memset+88>: movel %sp at +,%d2
0x800004ea <memset+90>: braw 0x800004f0 <memset+96>
0x800004ee <memset+94>: moveb %d0,%a0 at +
0x800004f0 <memset+96>: subql #1,%d1
0x800004f2 <memset+98>: bplw 0x800004ee <memset+94>
0x800004f6 <memset+102>: movel %sp@(4),%d0
0x800004fa <memset+106>: rts
End of assembler dump.
No DBCC there.
FWIW, I repeated the test with: m68k-rtems4.10-gcc -mcpu=68020 -v -O4 m.c
And, I did in fact get a dbf:
(gdb) disassem memset
Dump of assembler code for function memset:
0x80000490 <memset+0>: moveal %sp@(4),%a0
0x80000494 <memset+4>: movel %sp@(8),%d0
0x80000498 <memset+8>: movel %sp@(12),%d1
0x8000049c <memset+12>: cmpil #16,%d1
0x800004a2 <memset+18>: bcsw 0x800004f8 <memset+104>
0x800004a6 <memset+22>: movel %d2,%sp at -
0x800004a8 <memset+24>: moveb %d0,%d2
0x800004aa <memset+26>: lsll #8,%d0
0x800004ac <memset+28>: moveb %d2,%d0
0x800004ae <memset+30>: movew %d0,%d2
0x800004b0 <memset+32>: swap %d0
0x800004b2 <memset+34>: movew %d2,%d0
0x800004b4 <memset+36>: movel %a0,%d2
0x800004b6 <memset+38>: negl %d2
0x800004b8 <memset+40>: andil #3,%d2
0x800004be <memset+46>: beqw 0x800004d4 <memset+68>
0x800004c2 <memset+50>: subl %d2,%d1
0x800004c4 <memset+52>: lsrl #1,%d2
0x800004c6 <memset+54>: bccw 0x800004cc <memset+60>
0x800004ca <memset+58>: moveb %d0,%a0 at +
0x800004cc <memset+60>: lsrl #1,%d2
0x800004ce <memset+62>: bccw 0x800004d4 <memset+68>
0x800004d2 <memset+66>: movew %d0,%a0 at +
0x800004d4 <memset+68>: movel %d1,%d2
0x800004d6 <memset+70>: lsrl #2,%d2
0x800004d8 <memset+72>: subql #1,%d2
0x800004da <memset+74>: movel %d0,%a0 at +
0x800004dc <memset+76>: dbf %d2,0x800004da <memset+74>
0x800004e0 <memset+80>: subil #65536,%d2
0x800004e6 <memset+86>: bplw 0x800004da <memset+74>
0x800004ea <memset+90>: andil #3,%d1
0x800004f0 <memset+96>: movel %sp at +,%d2
0x800004f2 <memset+98>: braw 0x800004f8 <memset+104>
0x800004f6 <memset+102>: moveb %d0,%a0 at +
0x800004f8 <memset+104>: dbf %d1,0x800004f6 <memset+102>
0x800004fc <memset+108>: movel %sp@(4),%d0
0x80000500 <memset+112>: rts
0x80000502 <memset+114>: nop
End of assembler dump.
On Mar 30, 2010, at 3:26 PM, Joel Sherrill wrote:
>>
>
> Thanks for all the help. I have tracked it down to memset()
> which is definitely in assembly in newlib 1.18.0. Hmmm...
> This output from the -v on the link doesn't look like it used
> the right multilib:
>
> /users/joel/test-gcc/b-gcc1-m68k/gcc/testsuite/gcc/' '-v'
> /users/joel/test-gcc/b-gcc1-m68k/gcc/collect-ld -dc -dp -N -o /users/joel/test-gcc/b-gcc1-m68k/gcc/testsuite/gcc/zero-struct-2.x7 /users/joel/test-gcc/install-svn/m68k-rtems4.10/uC5282/lib/start.o /users/joel/test-gcc/b-gcc1-m68k/gcc/m5208/crti.o /users/joel/test-gcc/b-gcc1-m68k/gcc/m5208/crtbegin.o -e start -L/users/joel/test-gcc/b-gcc1-m68k/m68k-rtems4.10/./newlib -L/users/joel/test-gcc/b-gcc1-m68k/gcc/m5208 -L/users/joel/test-gcc/b-gcc1-m68k/gcc -L/users/joel/test-gcc/install-svn/m68k-rtems4.10/uC5282/lib -L/users/joel/test-gcc/b-gcc1-m68k/m68k-rtems4.10/./newlib /tmp/ccBTk1gL.wpa.ltrans.o gcc_tg.o /users/joel/test-gcc/b-gcc1-m68k/rtems_gcc_main.o -wrap exit -wrap _exit -wrap main -wrap abort -lm -lgcc --start-group -lrtemsbsp -lrtemscpu -lc -lgcc --end-group -T /users/joel/test-gcc/install-svn/m68k-rtems4.10/uC5282/lib/linkcmds -lgcc /users/joel/test-gcc/b-gcc1-m68k/gcc/m5208/crtend.o /users/joel/test-gcc/b-gcc1-m68k/gcc/m5208/crtn.o
>
> -mcpu=5282
>
> I don't see any explicit matches on 5282 in t-mlibs. Suggestions
> on how to fix this appreciated. This is an ugly file. :(
>
> --joel
>
--
Eric Norum
wenorum at lbl.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100330/e3f5e34d/attachment-0001.html>
More information about the users
mailing list