On Mon, Aug 06, 2012 at 09:59:40AM +0200, Michael Schnell wrote: > Yep. I suppose the addressing mode restriction might in fact be the > problem I see. > > The examples I observed were setting bits in memory > (hardware-addressing mode: read-modify write a memory cell in a > single instruction) and moving a value from memory to memory > (hardware-addressing mode: read-modify write two memory cells in a > single instruction). Both access memory twice in a single > instruction. Exactly this might be optimized out when moving from > 68K instruction set to Coldfire instruction set in order to reduce > the processor hardware complexity. > > The FIDO processor I use does provide these addressing modes. But in > fact, Innovasic does not provide a list of cycle counts for the > instructions. So maybe the compiler even is right not to use these > instructions because they use more cycles than the combination it > produces.
I wonder where you could get cycle counts for each instruction. I remember seeing them years ago for 8085 and such, but no idea of freescale provides them. > I don't see why a decent (not Coldfire aware) 68K-compiler should > not extensively use these features to create highly optimized code. Well if you can find a decent compiler it ought to do that. > Yep. but a "decent" 68 K compiler) will create more compact and > faster code for e.g. CPU32. Exactly this is the issue I intended to > discuss. My impression is, that the compiler I have, in fact > produces Coldfire code and not CPU32 code (that might be more > appropriate for FIDO) Seems quite likely. > When I - using the "68332" documentation - compare the code my GNU > compiler generates, against that which I think would be more > optimized (and that to some extent is generated by my 15 year old > MRI compiler) the GNU code is worse by a factor of two to four > regarding code size and cycle count. Of course this is only true for > these examples. With "normal" calculation that issue does not show > dramatically, as most work is done within registers (thus > "RISC-friendly"). gcc being a bad compiler is hardly surprising. One of my coworkers complained that he was looking as some disassembled powerpc object code in a debugger and even without much knowledge of powerpc it was obvious that there were things that would have been trivial to optimize which had not been optimized. I do hope clang+llvm turns out to be a better compiler soon. gcc has a vast list of supported architectures, but it sure isn't a great compiler for any of them. It is just so universally available. -- Len Sorensen _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
