Lpc2000

Robert Adsett wrote:

>At 01:23 PM 11/8/05 +0300, ????????? ??????? wrote:
>  
>
>>On Tue, 08 Nov 2005 04:47:49 -0500
>>  Tom Walsh <tom@...> wrote:
>>    
>>
>>>vaneenbergen wrote:
>>>
>>>      
>>>
>>>>That the first bit of the second byte also changed is very possible.
>>>>This is de to the processor. The timer register should be handled in
>>>>a 32 bit access. this is what i found out. so instead of these kind
>>>>of structures i just handle them in 32-bit. this way it is also
>>>>quicker, you can change all values at the same time.
>>>>
>>>>is this really the fault of the compiler?????
>>>>
>>>>
>>>>        
>>>>
>>>He didn't understand what it was that he wrote so how can he answer
>>>that
>>>question?
>>>
>>>
>>>TomW
>>>
>>>      
>>>
>>What you mean? I think it obviously, that it's really fault of
>>compiler. I explain my point of view to Paul
>>    
>>
>
>
>The compiler is doing exactly what you told it to.  You've just 
>(re)discovered that the behaviour of the construct you've used is 
>completely non-portable.  It certainly doesn't port between 
>architectures.  It doesn't port between compilers and it's possible that it 
>might not port between compiler versions.
>
>Bitfields are very seductive approaches to HW interfacing but after trying 
>them several times I've come to the conclusion that they are far more 
>effort than they are worth and are questionable even if you stick to the 
>same compiler (and version) on the same architecture.
>
>IMO the only thing bitfields are useful for is storing abstract flags and 
>sub integer sized values in structure that you want to memory 
>optimize.  They then act as a hint to the compiler that you want to use as 
>little room as possible at the expense of extra runtime.  They are not even 
>useful for binary file structures (they break across compilers/architecture 
>there as well)..
>
>  
>

I agree with you for the most part.  However there are data records that 
other systems send to me in a packed format that I either write a lot of 
code to unmangle, or simply describe it using packed attribute and 
bitfield definitions.

What I don't agree with is your statement about "at the expense of extra 
runtime".   As an assembly programmer for many years, I would be hard 
pressed to come up with some of the code sequences that the compiler 
produces!

For the most part, I try not to be too specific about how I code 
something so that the compiler can take advantage of optimizing my 
code.  The more specific I get about how an operation should proceed, 
the less leeway I'm allowing the optimizer to take.  Todays' code 
optimizers are amazingly efficient!


Regards,

TomW


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