Lpc2000

Dave,

O.K. but your explicit type cast is effectively saying to the 
compiler "I know what I'm doing".

I don't have any good 'C' reference to hand, so I can't quote the 
formal way of expressing this, but an explicit type cast is a 
direction to the compiler to forget any original type information 
and treat it as the type of object specified. The fact that the 
original type meant that it could or even would be on an un-alligned 
address is I believe not relevant. 

Don't forget that in the line "ip = (int *)&buf[i];" all it's doing 
is giving the "ip" variable a value: no address is being de-
referenced. It's the next line that does the actual copy, which as I 
pointed out is copying an integer sized object from one place to 
another. It's on this line that any platform specific issues (such 
as unalligned accesses being disallowed or undefined) will show up, 
and yet there's no problem with the line itself. You're expecting 
the compiler to remember (at compile-time) that the pointer may have 
an invalid address in it: a pretty tall order (for the general case: 
it happens to be obvious enough to a human programmer here).

By the way, what exactly are you trying to do here: is it just to 
illustrate a point? Even if it did byte sized reads and writes, the 
code doesn't make much sense (even ignoring the out of bounds 
problem).

Brendan

--- In lpc2000@yahoogroups.com, "dsidlauskas1" <dsidlauskas@...> 
wrote:
>
> Brendan,
> 
> The information to the compiler is in the line:
> 
>  ip = (int *)&buf[i];
> 
> Where it should be clear that the pointer is to an unaligned int.
> 
> Dave S.
> 
> --- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@>
> wrote:
> >
> > 
> > When you say "I believe that the compiler has enough information 
to 
> > use byte aligned transfers", are you refering to the line:
> > 
> > x[4] = *ip
> > 
> > If so, why do you expect byte transfers? You're copying from one 
> > integer sized object to another. What happened before this line 
is 
> > irrelevant (in particular the fact that you've forced the "ip" 
> > pointer to have a badly alligned value).
> > 
> > Or am I misunderstanding what you're asking?
> > 
> > Brendan
> > 
> > --- In lpc2000@yahoogroups.com, "dsidlauskas1" <dsidlauskas@> 
> > wrote:
> > >
> > > Consider the following code:
> > > 
> > > ============================
> > > char buf[]={1,2,3,4,5,6,7,8};
> > > int *ip, x[4];
> > > 
> > > for (i=0; i<4; i++)
> > >     {
> > >     ip = (int *)&buf[i];
> > >     x[4]  = *ip;
> > >     }
> > > =============================
> > > The Keil compiler compiles this without warning, but does not 
> > produce
> > > the expected (for me) result in x. The problem is that Keil 
uses the
> > > LDR instruction to effect the transfer and this is valid only 
on 4
> > > byte boundaries.
> > > 
> > > GCC compiles but does give a non-aligned access warning.
> > > 
> > > I believe that the compiler has enough information to use byte 
> > aligned
> > > transfers, and should, or at least give a warning.
> > > 
> > > Anybody want to weigh in on this one.
> > > 
> > > Thanks in advance for your comments.
> > > 
> > > Dave Sidlauskas
> > >
> >
>