On Wed, 3 Apr 2002, Mike Mansheim wrote:

> >>     eth_length = ((UI)workbuff[3] << 8) + (UI)workbuff[2];
> >>
> >>     eth_length = ((UI)workbuff[3] * 256) + (UI)workbuff[2];> That code should only take 4 instructions. How many instructions do
> > Hitech and CCS take?
>
> CCS compiles to 11 instructions (this is for an 18C452):

Mike,

Excellent job in conducting the comparison!

One nit picky comment, the 18C movff instruction occupies two program
words. So the optimal 2-instruction solution for the above code is in fact
four program words.

<snip>

>
> Of course, if I were pressed for code size, I would further eschew
> portability and use CCS's VERY handy #byte directive:
>
>   unsigned int16 eth_length;
>   #byte          eth_lo = eth_length
>   #byte          eth_hi = eth_length + 1

I'm curious. Why not just use an ANSI supported union that overlays two
bytes on a 16-bit integer? Macros can then be written to type cast
eth_length to a union and select the lo and high bytes individually. If
endian issues arise, then #defines can handle them. (I don't have time to
write an example at the moment, but what I'm getting at is that a compiler
depedent include file could be created to abstract the compiler nuances.
For example, I have a bit macro that I use to declare bits at absolute
addresses that will work with SDCC and Hi-Tech [I used this to convert Bob
Blick's LCD terminal program into something that can be compiled by
SDCC.])


for the f877:

> eth_length = ((UI)workbuff[3] << 8) + (UI)workbuff[2];   15 instructions
> eth_length = ((UI)workbuff[3] * 256) + (UI)workbuff[2];  47 instructions!
> with #byte's:  4 instructions

yikes! 15 sounds about like SDCC. 47 sounds like the multiplication code
is being in-lined. 4 sounds really good!

Again Mike, thanks for running through the comparison.

Scott

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics