[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] C bit
> > > > 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
> (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: email@example.com
of Technology | .signatures | firstname.lastname@example.org
| so hard to do | WWW/ftp: rand.thn.htu.se
Gothenburg, Sweden | well? | (MGIFv5, QLem, BAD MOOD)