Re: m68k machine description question

[John Vickers <John dot Vickers at PaceMicro dot com>]

paul.andrews@smartmove.co.nz wrote:
> 
> I have recently (finally!) managed to get a m68k targeted gcc up and going with
> our hardware, but I have noticed something odd. The compiler seems to *always*
> generate calls to the libgcc helper functions for multiply, divide and modulo.

> I tried to have a look around the sources to see why this might be but I got a
> bit lost. From what I did manage to understand I suspect the m68k.md file may
> be the 'culprit'. All of the definitions for these operations appear to only
> support direct instructions on 68020+. 

> The 68000 core has perfectly good
> mulu/divu muls/divs instructions. 
> Can anyone tell me why they are not used?

The problem is that on the 68{,HC,EC,SEC}000 core, muls/mulu
only do 16x16->32 and divs/divu only do 32/16->16,16.

But as you say, the back end should probably still use them,
for 32x32->32 multiplies and 32/16 divmod.
32/32 divides involve to many cases to be sensibly inlined.

I found that inlining 32-bit (SImode) multiplies on 68000
often shrank the code, because of better register allocation.

In the division-by constant case, the trick is to test the V-bit
after the divide: in most cases only one divide instruction is necessary.

I did this stuff a two or three years ago, but for various reasons,
including the general hassle of gcc2, this never got submitted.
It would need a certain ammount of hacking to bring it up to date,
and the general approach of putting loads more code in m68k.c is
frowned on these days, as far as I can tell.

Code generation for the 68000 was quite poor: the m68k port
basically seemed to be a 68020 port, with a few tweaks to make it
work on the other cores.  Even on the 68020 there was a lot of room for
improvement.

If you're interested, I think my former employer would be happy
to let you have a copy of this mul/div stuff.  And for that matter
a pile of other stuff for the various m68k cores...

The 68k has reached the end of the line:  wouldn't you
folks be better off looking at ARM or SH or low end MIPS/PPC ?

Regards,

John