From: Spehro Pefhany
Subject: Re: To C or not to C
References: <email@example.com> <01c2b41a$cafe2d80$a893eb41@stupidwin95> <firstname.lastname@example.org>
X-Newsreader: Forte Agent 1.92/32.572
Date: Sun, 05 Jan 2003 16:36:45 GMT
NNTP-Posting-Date: Sun, 05 Jan 2003 11:36:45 EST
On Sun, 5 Jan 2003 10:45:32 -0500, the renowned "D Poinsett"
>You are absolutely right about the inefficiency of a 16x16 when all that is
>needed is 8x8.
What I meant was this
[15...0] * [15...0] -> [15..0][15...0]
C integer math routines give you the least significant two bytes A of
the result, any result greater than 0x7FFF (signed) will cause an
overflow, which is *ignored*.
For control and similar purposes, we often want to consider the
numbers as fractional or with a fixed decimal point. In the fractional
case, it is equivalent to selecting the result B. We'd also often want
to either detect an over/underflow or (even better, usually) to
"saturate" the result at the largest +ve or -ve number, similar to
what an analog circuit does. What we DON'T want is the "phase
reversal" on overflow that C integer math does, which can cause
obvious problems in control loops.
Now, you can substitute longs for ints in the above and just select
the part of the result you want ( >> 16 for unsigned numbers), but
that means you have to do 4x the work - O(n^2) for n bits.
Your example, 8 x 8 -> 16 is somewhat similar. In an 8051
you'd just use an inline assembly code instruction for multiply,
which will do unsigned 8 x 8 -> 16 multiply in the chip's
microcode- not as fast as the hardware 16 x 16 multiplier in
the MSP430 or the hardware 8 x 8 multiplier in a few of the PICs,
but pretty darned good.
"it's the network..." "The Journey is the reward"
email@example.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com