SV: [Icc-avr] Casting
Bengt Ragnemalm
benra at imt.liu.se
Tue Jan 15 00:19:22 PST 2008
And thats the reason that I never use int, I always use short instead. Is
there any a reason to use int? We have char, short and long and thats all
we need.
For the upper and lower byte capture I think it is most important that the
code is readable but also to find the method that is most efficient as you
will always run into situations there you run out of FLASH and have not the
option to step into a larger AVR until maybe the next prototype. Therefore I
like to find the most efficient code for this type of tasks as we will see
them all over again. Of course the best method will vary over time depending
on the compiler but I try to find a good compromise. Also unreadable code is
not tolerable. If shifting is the most efficient way, why not use a macro
like:
USHORT_MSB(x) = (x >> 8)
USHORT_LSB(x) = (unsigned char)(x)
/Bengt
> -----Ursprungligt meddelande-----
> Från: icc-avr-bounces at imagecraft.com [mailto:icc-avr-
> bounces at imagecraft.com] För Johannes Assenbaum
> Skickat: den 14 januari 2008 23:30
> Till: icc-avr at imagecraft.com
> Ämne: RE: [Icc-avr] Casting
>
> I don't beleive in "high" and "low" operators to be really useful at c
> level, because compiler basically is free to generate different code
> depending on (default) int size. I.e. with int=16bits, high() and low()
> may result in bytes, but with int=32bits you'll get 16bit words.
>
> Whereas "XXX >> 8" always is meaning byte shift for compiler as well as
> for coder/reader.
>
> Superfluous instructions can be expected to be omitted by compiler anyway.
> (as by iccavr.)
>
> Johannes
>
>
> > Some compilers have operators like "high()" and "low()", which makes it
> > clear to the compiler (and to the reader) that that is exactly the
> > simple thing that you want: just use the appropriate address and no
> > superfluous instructions.
>
> > Albert.
>
>
> > -----Original Message-----
> > From: icc-avr-bounces at imagecraft.com
> > [mailto:icc-avr-bounces at imagecraft.com] On Behalf Of Johannes Assenbaum
> > Sent: Tuesday, January 15, 2008 08:41 AM
> > To: icc-avr at imagecraft.com
> > Subject: Re: [Icc-avr] Casting
>
> > As someone mentioned before, this is only safe for Little Endian, but as
> > AVRs are Little Endian, there will be no problem with iccavr.
>
> > Btw: Shortest code (no optimisation enabled) will be with source value
> > casted.
>
> > Data[7] = ((unsigned int)(Channel_One) >> 8); Data[8] = ((unsigned
> > int)(Channel_One));
>
> > Best regards,
> > Johannes
>
>
> >>> Andrew wrote:
> >>>> Hi,
> >>>>
> >>>> When casting and int to two char' (a MSB and LSB) is it safe to do
> >>>> the
> >>>> following:-
> >>>> Data[7] = (Channel_One >> 8);
> >>>> Data[8] = (Channel_One);
> >>>>
>
> >> I always use the above solution, it should be perfectly legal and it
> >> has never failed me on any compiler. I think it is quite clear for any
>
> >> programmer of embedded systems what this does.
>
> >> regards
> >> Johan
>
>
> >> _______________________________________________
> >> Icc-avr mailing list
> >> Icc-avr at imagecraft.com
> >> http://dragonsgate.net/mailman/listinfo/icc-avr
>
>
> >> --
> >> No virus found in this incoming message.
> >> Checked by AVG Free Edition.
> >> Version: 7.5.516 / Virus Database: 269.19.2/1223 - Release Date:
> >> 13.01.08 20:23
>
>
>
> > _______________________________________________
> > Icc-avr mailing list
> > Icc-avr at imagecraft.com
> > http://dragonsgate.net/mailman/listinfo/icc-avr
>
> > Scanned by Bizo Email Filter
>
>
>
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.516 / Virus Database: 269.19.2/1223 - Release Date:
> 13.01.08 20:23
>
>
>
> _______________________________________________
> Icc-avr mailing list
> Icc-avr at imagecraft.com
> http://dragonsgate.net/mailman/listinfo/icc-avr
More information about the Icc-avr
mailing list