Re: [MiNT] C bit

[Johan Klockars <rand@cd.chalmers.se>]

> > > > Compiler output (-m68030 -O3):
...
> > > > 	mulu.l	#$cccccccd,d0-d2
...
> > I'd guess that this optimization is done in the hardware independent part
> > of GCC and that code may assume a larger difference between MUL and DIV
> > timings than the '030 has.
> >
> 
> Perhaps I am missing something, but IMHO the remainder is never bigger

You are.

> (neither has bigger size), than the divisor. So to calculate the remainder
> of a division by constant 5, the "normal" divu.w can be used, which is 2

For the sake of simplicity, assume that we have a divu.b instruction and
want to calculate 257 modulo 5.
It's obvious that the result is really 2, but the divu.b instruction would
only see the lower 8 bits, that is 1. 1 modulo 5 != 2...

That is, you need to use the complete number to get the correct modulo result.
(Unless the number you divide by is a power of two, but then of course you
 would use an AND rather than a DIVU, anyway.)

This is really the same thing as trying to figure out the remainder of
130/13 by only looking at 30/13.

> > MULU.L never takes more than 44 cycles on the '030.
> 
> 44 cycles plus "fetch immediate effective address time", which is 2 cycles
> in this case.

I guess I should have mentioned those, but they are always there. My main
point was that it was quite a bit faster than the 60 cycles the original
poster guessed at.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johan@rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)