Re: Incorrect code using gcc 2.8.x for Motorola 5200 Coldfire

[John Vickers <jvickers at acorn dot com>]

Jeffrey A Law wrote:
> 
>   In message <35EB1E68.19E3FCDD@intellistor.com>you write:
>   >
>   > Correct.  I didn't state that clearly enough.  Upon reading the
>   > 68020, 68030, 68040, 5202, 5206 and 5307 programmers references;
>   > it appears that a "movea.w" is not allowed on any of these
>   > processors (i.e. a byte move into or out of an address register).
> Err, "movea.w" != byte.
> 
> I spent a little more time looking at the code, and for other m68k
> variants we only disallow QImode loads/stores to/from address registers.
> 
> For a byte copy we'll actually generate a word sized copy.  So, does
> the 5307 allow mov.w #<immedaite>,aX or mov.w reg0,reg1 where
> reg0 and/or reg1 are address registers?

If you do any kind of operation with an address reg destination,
all the bits (QI,HI,SI)
are changed - that's how it's built.  You shouldn't be thinking
about what width is the closest.
They're all effectively (set (reg:SI ) (...) ).

The machine instructions you probably want on CF
for i->a  are lea %a0:w,%1  and  subl %0,%0.
If move_qimode punts to move_simode_const, the decisions about which
instruction is best for what value & what target stay in one place.

If we have QImode n->da, we should sign-extend the low 8-bits, & use
move_simode
(this gives e.g. moveq #-1,d0 instead of move.b #0xFF,d0).
If move_simode doesn't give good code, then we fix that & improve
the SImode stuff as well.  This should also be done for HImode,
so we get moveq #-1,d0 instead of move.w #0xFFFF,d0
 
> If so, then the better solution is easy.  We fix the constraints to disallow
> QImode load/stores to/from address regs and tweak output_movve_qimode
> to use the ".w" extension instead of hte ".b" extension for something
> which references an address reg.

move.l is better on the '060 (& possibly some of the CF's):
on the '060, movl ri<Q>o,r  is zero latency, i.e. result can be used
in another instruction which issues in the same clock
(if the core has spare bandwidth to fetch such an instruction).
On the '060 moveq is also zero latency.  On all of the other
targets move.l r,a never worse than move.w.  I also have a vague
recollection
that move.w ri,a is slow on at least one target (possibly the '040).

Byte & word ops with a dreg dest have a built-in dependency on the
dest reg (as far as the hardware is concerned), so sometimes we should
prefer long ops to implement QI & HI insns.
  
Since move_qimode is really deciding to do a SImode reg move instead,
maybe it's tidier to punt to move_simode_whatever. 

One day I might dust off a few 100k of patches.  I think I'll have
some more free time in November 2001. 

John.