[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: mint@fishpool.com*Subject*: Re: [MiNT] C bit*From*: Johan Klockars <rand@cd.chalmers.se>*Date*: Wed, 10 Nov 1999 16:53:57 +0100 (MET)*In-reply-to*: <Pine.BSF.3.95q.991110152825.27531B-100000@antyk.obta.uw.edu.pl> from "Konrad M. Kokoszkiewicz" at Nov 10, 99 03:32:56 pm*Sender*: owner-mint@fishpool.com

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

**Follow-Ups**:**Re: [MiNT] C bit***From:*"Konrad M. Kokoszkiewicz" <draco@obta.uw.edu.pl>

**References**:**Re: [MiNT] C bit***From:*"Konrad M. Kokoszkiewicz" <draco@obta.uw.edu.pl>

- Prev by Date:
**RE: [MiNT] Security again** - Next by Date:
**RE: [MiNT] Security again** - Previous by thread:
**Re: [MiNT] C bit** - Next by thread:
**Re: [MiNT] C bit** - Index(es):