[uClinux-dev] 68K GNU Compiler

Michael Schnell mschnell at lumino.de
Mon Aug 6 03:59:40 EDT 2012

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").


More information about the uClinux-dev mailing list