Re: A89: Shifting/Multiplying. . .
[Prev][Next][Index][Thread]
Re: A89: Shifting/Multiplying. . .
> I think that mulu would be a bit faster. Give or take a byte, each
It depends. If you multiply with a constant, you can quite often beat
mulu.
> instruction is three bytes long. Seeing that the processor is 32-bit, it
To be precise, all instruction opcodes are 2 bytes long. *NO* exception.
An instruction can have 0 - 4 extension words which encode the
information needed to calculate the effective address. For all
practical purposes the extension words are part of the instruction
code, so intructions can be 2,4,6,8 or 10 bytes long.
> doesn't really matter in performance speed, but if you have many
While the processor is 32 bit, the following is true:
- It has a 16 bit data bus, that is, accessing a 32-bit object in
memory takes twice as much time as to access a 16 bit one.
- Even internal operations (like reg-reg adds) are slower for 32 bit
operands than for 16 bit ones.
> instances of it, go with the mulu. You'll find that your program will
> run faster, since every time you want to call the subroutine, you need to
> tack on a few more bytes (to save program counter, push arguments, etc.).
It is true. If you make the multiply by constant a *subroutine* then you
will probably lose. A bsr / rts pair takes 18+16 = 34 clocks. It would
be a rare case that you could come up with something that is that much
faster than mulu. On the other hand, if you just put the whole routine
into your code (no calls) then you often can win against mulu (for
constants).
> But I'm just a beginner. Zoltan, insert your words of wisdom. =)
Just did :-)
Regards,
Zoltan
Follow-Ups:
References: