From: "D Poinsett"
Subject: Re: To C or not to C
Date: Sun, 5 Jan 2003 11:51:34 -0500
Organization: Posted via Supernews, http://www.supernews.com
References: <firstname.lastname@example.org> <01c2b41a$cafe2d80$a893eb41@stupidwin95> <email@example.com>
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
My mistake. I see what you mean about 16x16 -> 16.
Integer math in embedded applications requires great attention to detail. I
have been bitten many times by that sign bit! If only the users of our
products knew how we suffer for them :-)
Have you used the HC11 with its hardware fractional divide instruction? A
For most of my projects, the occasional use of long integer math is
manageable in terms of speed and code size. A project a couple of years ago
needed lots of 32-bit math executing swiftly so I used the HC12 and wrote
the time critical sections in inline assembly. I love the chip.
"Spehro Pefhany" wrote in message
> On Sun, 5 Jan 2003 10:45:32 -0500, the renowned "D Poinsett"
> >Hi Spehro,
> >You are absolutely right about the inefficiency of a 16x16 when all that
> >needed is 8x8.
> What I meant was this
> B A
> [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.
> Best regards,
> Spehro Pefhany
> "it's the network..." "The Journey is the reward"
> firstname.lastname@example.org Info for manufacturers:
> Embedded software/hardware/analog Info for designers: