Re: [Dorset] gcc cross compiling to m68k
Hi Tim,
Generated code looks OK
Something I used to find gcc didn't cope too well with when targetting
ARM was the C idiom `!!x' to map 0 onto 0, and everything else onto 1.
IOW, `x ? 1 : 0'.
For
signed int nnsi( int x) { return !!x; }
unsigned int nnui(unsigned int x) { return !!x; }
signed int tosi( int x) { return x ? 1 : 0; }
unsigned int toui(unsigned int x) { return x ? 1 : 0; }
this gcc with -O3 produces the same x86 for all four,
pushl %ebp
xorl %eax, %eax
movl %esp, %ebp
cmpl $0, 8(%ebp)
popl %ebp
setne %al
ret
I think ARM needs two instructions, ignoring function prologue and
epilogue,
teq r0, #0 ; nflag, zflag = r0 xor 0
movne r0, #1 ; if not zflag: r0 = 1
; else: r0 already 0
Perhaps gcc on ARM does better these days.
Cheers,
Ralph.
--
Next meeting: Bournemouth? TBD, Wednesday 2010-10-06 20:00
Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/
How to Report Bugs Effectively: http://bit.ly/4sACa
Re: [Dorset] gcc cross compiling to m68k
Hi Tim, 86 0030 4AAE 0008 tst.l 8(%fp) 87 0034 56C0 sne %d0 88 0036 4E5E unlk %fp 89 .cfi_offset 14, -8 90 0038 7100 mvs.b %d0,%d0 91 003a 4480 neg.l %d0 92 003c 4E75 rts I don't know 68000/Coldfire so I'm enjoying this. :-) tst.l 8(%fp) ; compare x to 0. sne %d0 ; if x != 0: d0 = 0xff. unlk %fp ; prepare for return. mvs.b %d0,%d0; sign-extend the byte in d0 to be 32-bit. neg.l %d0; d0 = 0 - d0. 0 stays 0, -1 becomes 1. rts ; return. At first glance not sure why the mvs.b is necessary. I agree. It could be (* marks change) tst.l 8(%fp) ; compare x to 0. sne %d0 ; if x != 0: d0 = 0xff. unlk %fp ; prepare for return. * neg.b %d0; d0 = 0 - d0. 0 stays 0, -1 becomes 1. rts ; return. if the neg.l became a neg.b. I guess it's because it knows it's returning a 32-bit int and doesn't see it can stick with 8-bit. Cheers, Ralph. -- Next meeting: Bournemouth? TBD, Wednesday 2010-10-06 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://bit.ly/4sACa
Re: [Dorset] gcc cross compiling to m68k
Hi Dan and Ralph On 06/09/10 22:03, Dan Dart wrote: initial questions, if anyone on the list has experience using gcc as a cross-compiler. Yep - I use buildroot a lot. What's multilib and how does it fit in with newlib (which I gather I need to build for a different target)? Multilib is a feature of gcc that lets you compile for multiple architectures with one binary e.g. x86/x86_64, or even x86/ppc (I think) Newlib is a C library, replacing glibc or µclibc Do I need to do a specific gcc build for m68k (I'm assuming yes, but confirmation would be nice!). Most definitely. You need gcc to compile a static gcc that compiles code for m68k on your architecture. And maybe including a m68k version of gcc (only runs on m68k) I assume I also need to build binutils for m68k too? Most definitely again. That's the second thing you put in your toolchain, after kernel headers. You compile gcc against that. Hope that helps Certainly does. It's turning out to be a bit of project because of gcc/newlib interdependencies which means having to build a bootstrap gcc, then newlib, then finally gcc again with newlib. I'm currently at the first stage of this, after a few abortive attempts. Cheers Tim -- Next meeting: Blandford Forum, Tuesday 2010-09-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://bit.ly/4sACa
Re: [Dorset] gcc cross compiling to m68k
Hi Tim, It's turning out to be a bit of project because of gcc/newlib interdependencies which means having to build a bootstrap gcc, then newlib, then finally gcc again with newlib. I'm surprised an x86-host m68k-target gcc needs to be built with an m68k newlib to hand? Cheers, Ralph. -- Next meeting: Blandford Forum, Tuesday 2010-09-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://bit.ly/4sACa
Re: [Dorset] gcc cross compiling to m68k
Hi Dan, I'm surprised newlib is in use here at all. Did you choose it, and if so why? I'm not a newlib buff so I won't know about how it's awesome quite yet I'm afraid. If all else fails, check out buildroot as it can probably make you a toolchain, plus a load of userspace stuff, based on µClibc/busybox. I know newlib has some support for non-Linux embedded targets, e.g. those without an OS, I don't know if uClibc does. http://buildroot.uclibc.org/about.html looks useful, but there's something about understanding how to get cross-compilation going yourself, especially if you want to examine and tinker with the code it's producing. Cheers, Ralph. -- Next meeting: Blandford Forum, Tuesday 2010-09-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://bit.ly/4sACa
Re: [Dorset] gcc cross compiling to m68k
Hi Dan On 07/09/10 12:52, Dan Dart wrote: Hi, I'm surprised newlib is in use here at all. Did you choose it, and if so why? Yes, because at this stage I don't know any better. This is all totally new territory for me. I'm not a newlib buff so I won't know about how it's awesome quite yet I'm afraid. If all else fails, check out buildroot as it can probably make you a toolchain, plus a load of userspace stuff, based on µClibc/busybox. Um, my target system has a grand total of 8K of RAM and 128K of flash. Actually that answers your first question - newlib is suitable for embedded systems without any OS, which I what I have here. Cheers Tim -- Next meeting: Blandford Forum, Tuesday 2010-09-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://bit.ly/4sACa -- Next meeting: Blandford Forum, Tuesday 2010-09-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://bit.ly/4sACa
Re: [Dorset] gcc cross compiling to m68k
On 07/09/10 13:15, Ralph Corderoy wrote: Hi Dan, I'm surprised newlib is in use here at all. Did you choose it, and if so why? I'm not a newlib buff so I won't know about how it's awesome quite yet I'm afraid. If all else fails, check out buildroot as it can probably make you a toolchain, plus a load of userspace stuff, based on µClibc/busybox. I know newlib has some support for non-Linux embedded targets, e.g. those without an OS, I don't know if uClibc does. http://buildroot.uclibc.org/about.html looks useful, but there's something about understanding how to get cross-compilation going yourself, especially if you want to examine and tinker with the code it's producing. Well after almost a whole day of compiling gcc and newlib, I've actually got the cross-compiling gcc compiling a short test program to Coldfire. Generated code looks OK - but could be a couple more day's effort before I actually get something running on a target as still need to link. Cheers Tim -- Next meeting: Blandford Forum, Tuesday 2010-09-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://bit.ly/4sACa
Re: [Dorset] gcc cross compiling to m68k
initial questions, if anyone on the list has experience using gcc as a cross-compiler. Yep - I use buildroot a lot. What's multilib and how does it fit in with newlib (which I gather I need to build for a different target)? Multilib is a feature of gcc that lets you compile for multiple architectures with one binary e.g. x86/x86_64, or even x86/ppc (I think) Newlib is a C library, replacing glibc or µclibc Do I need to do a specific gcc build for m68k (I'm assuming yes, but confirmation would be nice!). Most definitely. You need gcc to compile a static gcc that compiles code for m68k on your architecture. And maybe including a m68k version of gcc (only runs on m68k) I assume I also need to build binutils for m68k too? Most definitely again. That's the second thing you put in your toolchain, after kernel headers. You compile gcc against that. Hope that helps Dan -- Next meeting: Blandford Forum, Tuesday 2010-09-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://bit.ly/4sACa
Re: [Dorset] gcc cross compiling to m68k
Hi Tim, I'm trying to get started on evaluating gcc for generating m68k code for embedded targets. I'm using Debian 5.0 but can pull in more recent gcc source if required. I've spent a few hours Googlin' around and have some initial questions, if anyone on the list has experience using gcc as a cross-compiler. I've done `build ARM on x86' ages ago, and the `three-stage bootstrap' before that to get a decent compiler on Ultrix, a Unix from DEC, but nothing more recent, I install what others have built, so this could be out of date... What's multilib and how does it fit in with newlib (which I gather I need to build for a different target)? I don't think multilib is relevant to what you're doing. Presumably, this is non-Linux, and you're primarily interested in the quality of code gcc produces. Building newlib with your cross-compiling toolchain gives you a C library, if you need one. Do I need to do a specific gcc build for m68k (I'm assuming yes, but confirmation would be nice!). Yes, I think gcc only supports the one target you state when it's built, unlike LLVM and clang, IIRC, which can have a whole load thrown in and you choose at run-time. (LLVM doesn't support m68k though AFAICS. Perhaps in time. It has some experimental PIC16 support now.) I assume I also need to build binutils for m68k too? Yes. I've always thought the `toolchain' people refer to is the group of target-architecture-specific commands to get from textual source to runable binary, e.g. ELF, COFF, or just hex. as(1), cc(1), ld(1), and so on. binutils provides some of them. But it seems it may be wider than that and include make(1), etc., which don't need to know of the cross-compilation. You may find http://vmlinux.org/crash/mirror/www.objsw.com/CrossGCC/FAQ.html of use. I can't contact the author's site, and it's probably out of date, but chapter four gives an idea of the steps involved. Cheers, Ralph. -- Next meeting: Blandford Forum, Tuesday 2010-09-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://bit.ly/4sACa
