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