On 08/03/2012 05:42 PM, Lennart Sorensen wrote:
My understanding is that the coldfire is still m68k, but has dropped
BCD support as well as some addressing modes from the instructions.
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.
So it is partially object compatible as long as the code doesn't use
any of the removed features.
I don't see why a decent (not Coldfire aware) 68K-compiler should not
extensively use these features to create highly optimized code.
According to freescale most coldfire object code will execute on the m68k
chips since the coldfire instruction set is pretty much just a subset
of the m68k.
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)
So if the compiler can generate code for the coldfire,
then that code ought to work fine on the m68k, although it could perhaps
have made it slightly more efficient by using some of the instructions
that are missing on the coldfire.
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").
-Michael
_______________________________________________
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
