Hi all,

Before you get too carried away with such complicated constructs check
the type of code the compiler produces.  Each time I use the Bytecraft C
compiler for something new I look at the assembler.  I tweak what I do
for either fastest operation or smallest code size.  The techniques to
get one or the other aren't always the same.

For example.  Bytecraft's optimization for

  char1 = my_16bitInt >> 8;

doesn't create a sequence of 8 rotate operations to move the byte
downward.  It just takes the top byte and assigns it into char1 and on
top of it all it's clean C code that's easy to read.

  char2 = my_16bitInt;

The compiler does an automatic type cast of the expression (my_16bitInt)
and casts it to the type of the L_VALUE the 8 bit sized char2 thereby
stripping the high part and assigning the low part.  A really good
compiler would issue a warning that some precision has been lost in the
assignment just in case you didn't intend to do this.

So the code that is generated is the exact same set of instructions
you'd use if you were writing in assembler.

If the compiler isn't clever enough to figure out that "{expression} >>
8"  is the top byte then the compiler writers haven't done their job.

Another quicky way to pull an integer out of an array of bytes is as
follows.

My_16bitInt = *(WORD *)&bytearray[5];

This tells the compiler that we want the address of the location
bytearray[5].  We are telling the compiler it should treat that address
as a pointer to a word and then we use the '*' to dereference that
pointer and move the two bytes as an integer into the variable
My_16bitInt.

Try that.  Again,  since the absolute address of the array is specified
by the index '5', this turns into 4 PIC instructions.  You just have to
ensure that your byte array keeps the correct low/high byte ordering for
16 bit integers.

Regards.

John

> -----Original Message-----
> From: pic microcontroller discussion list
> [mailto:PICLIST@MITVMA.MIT.EDU] On Behalf Of Scott Dattalo
> Sent: Friday, April 05, 2002 1:33 PM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: [pic] c compiler comparison
>
>
> On Fri, 5 Apr 2002, Mike Mansheim wrote:
>
> > Because I'm not a C expert, but this got me to look at it
> (even though
> > I only have a Herbert Schildt book to look at).  I didn't
> see a way to
> > access the other members of the union other than using an
> array, which
> > makes the dot references cumbersome.  So I used #defines to
> make those
> > look better, and ended up with:
>
> <snip>
>
> Try this:
>
> #include <stdio.h>
>
> union lo_hi {
>   unsigned int i;
>   struct {
>     unsigned char l;
>     unsigned char h;
>   } b;
> };
>
> typedef union lo_hi lo_hi;
>
> #define LO_BYTE(x) ( ((lo_hi)(x)).b.l)
> #define HI_BYTE(x) ( ((lo_hi)(x)).b.h)
>
> unsigned int  evt_length;
>
>
> int
> main(int argc, char **argv)
> {
>
>
>   evt_length = 0x1234;
>
>   printf(" int 0x%02x, low byte 0x%02x, high byte  0x%02x\n",
>          evt_length,
>          LO_BYTE(evt_length),
>          HI_BYTE(evt_length));
>
>   return 0;
> }
>
>
> Scott
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email listserv@mitvma.mit.edu with SET PICList DIGEST in the body
>
>
>
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body