Lpc2000

Richard wrote:

>When you use an explicit cast, you are telling the compiler that you know 
>what you are doing and the compiler should leave you alone, so that's what 
>it did. For example, if you always ensure that the buf starts at an even 
>address, and that you only do things like
>         tmp = *(unsigned short *)&buf[i];
>where i is even, then the warning would be unnecessary.
>
>Bottom line - casts should not be used willy nilly without fully 
>understanding what's happening.
>
>  
>

Yeah, reminds me about something I did with a cast recently to extract a 
long from char array (buffer).  I cast the heck out of that reference to 
the char array and gcc did let me extract a long from it..  On an uneven 
boundry, the processor (LPC2138) didn't throw an exception, but it sort 
of got "a value" from the array, but the not the value I was expecting!  
Heh, the upper byte (MSD) was, how shall I say it, "wrong". heh

I learned my lesson about coercing gcc + ARM to do some things with type 
casts.  Now I'm a little more conservative about how I cast references 
to objects.

Regards,

TomW



>At 01:17 PM 11/16/2005, Marko Panger wrote:
>
>  
>
>>Hello all,
>>
>>I have a general programming question. Me and my co-workers had an
>>discussion about data alignment and non-aligned accesses. Please
>>consider the following situation where an un-aligned access was made
>>resulting in wrong value.
>>
>>char buf[5] = {1,2,3,4,5};
>>
>>unsigned short tmp;
>>
>>tmp = *(unsigned short*)&buf[1];       /* &buf[1] is on a odd address
>>
>>My co-workers expected that tmp will contain the value0x0203, but the
>>value was 0x02. I understand that, because ARM7 core does not support
>>un-aligned accesses and the compiler was forced to use a word access on
>>a odd address. This code was ported from an 8-bit machine where it was,
>>off course, working. My question is if all 32-bit devices would have the
>>same problem with this code and why when we tested the same situation on
>>a PC using Borland Builder compiler it was working as my co-workers
>>expected. Is this a CPU(+cpu bus) issue or it is also compiler dependent.
>>
>>Although I thing this is bad programming practice and it calls for
>>errors I am asking if it is possible to enable a warning for such
>>situations.
>>
>>Regards,
>>Marko
>>
>>
>>    
>>
>
>// richard (This email is for mailing lists. To reach me directly, please 
>use richard at imagecraft.com) 
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------