Lpc2000

Marko Panger wrote:

>Hi,
>
>Your replies are just what I was looking for. I needed a confirmation of 
>my understanding and I got it. For me, is normal not to receive a 
>warning in this situation because the compiler was forced by you. And 
>yes, different micros will react differently. Some will issue bus error, 
>some will read incorrect value and so on. My co-workers claimed up on 
>the micro and compiler that this should be handled but I really can't 
>imagine how if the compiler was forced.
>
>This code was ported from an 8 bit machine (with 8 bit data bus) when 
>such things works regardless of "buf" alignment, because buf is accessed 
>every time 8 bit, regardless of the cast.
>
>  
>
Yes, you can do that too with the ARM processor, but you describe that 
type of data as "__attribute__((packed))"  to signal the compiler to 
treat the structure differently.  With a 'packed' attribute, the 
accesses to various parts of the structure may be done on a long, word  
by word, or byte by byte basis, depending.

TomW


>The only thing that I was surprised was my PC box where this was possible.
>
>My conclusion is that un-supported un-aligned accesses are not 
>compiler/cpu bug but are compiler/cpu FEATURE and a skilled programmers 
>should RTFM and be aware of this.
>
>Thanks for you replies !
>
>marko
>
>Robert Adsett wrote:
>
>  
>
>>At 10:22 PM 12/16/05 +0100, Marko Panger wrote:
>> 
>>
>>    
>>
>>>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.
>>>   
>>>
>>>      
>>>
>>Compiler, micro and possibly more could play a role.  ANSI and ISO give the 
>>compiler leeway to do just about anything at this point.  Some micros will 
>>have a bus fault, some will read the incorrect value and some will read the 
>>'correct' value.  Note that whether the problem shows up may also depend on 
>>what else is in memory since the compiler is certainly free to place buf 
>>such that it starts on an odd address at which point buf[1] is suddenly on 
>>an even address.  Of course on a recompile it might change.  All of a 
>>sudden you have yourself a Heisenbug.
>>
>>The correct value at this point is also open to question even if alignment 
>>isn't an issue since that still leaves byte ordering and that varies across 
>>micros.
>>
>> 
>>
>>    
>>
>>>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.
>>>   
>>>
>>>      
>>>
>>Yes, but the cast will likely trip you up.  PC-Lint gives me a warning 
>>about a cast from a pointer to a pointer but  that is probably not a 
>>sufficient warning.
>>
>>Depending on what you are trying to do there are alternatives that will 
>>work reasonably portably.
>>
>>Robert
>>
>>" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
>>they legal, genetic, or physical.  If you don't believe me, try to chew a 
>>radio signal. "  -- Kelvin Throop, III
>>http://www.aeolusdevelopment.com/
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>> 
>>
>>    
>>
>
>
>
>[Non-text portions of this message have been removed]
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>


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