Lpc2000

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)..

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/