From: "D Poinsett"
Subject: Re: To C or not to C
Date: Sun, 5 Jan 2003 10:45:32 -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
You are absolutely right about the inefficiency of a 16x16 when all that is
needed is 8x8. The code is slower and slightly bigger and calls to the
function require the added inefficiency of needing to be set up to pass 16
bit values rather than 8, but for most of my projects, the penalty is minor
compared to having to do the whole thing in assembler. Perhaps there are
compilers that can detect or be instructed to use the appropriate sized
Your example reinforces the idea that the embedded designer needs to make
intelligent choices when issues of speed and code size are important.
"Spehro Pefhany" wrote in message
> snip snip...
> Unfortunately, C does not support this natively. The fixed point math
> available in C, especially when implemented on an 8-bit processor, is
> very inefficient. If you look at the code to do a 16 x 16 bit
> multiply, yielding a fractional 16 bit result, it's about 4 times
> what it should be in terms of execution time, because you have
> to use longs and throw away half the result. The code is bigger
> as well, IME, as the runtime routines for longs are not linked in
> unless they are needed.