Lpc2000

Brendan,

You make a good case in your second paragraph.

The exampe I've presented is just a toy problem. The real case is
porting a lot of old Z80 code where such constructs work just fine
because everything is byte aligned. 

I would think that most compilers have implicit unaligned data types,
if for nothing else than to deal with byte packed structures.

In casting up from a byte aligned structure, why couldn't (shouldn't)
the compiler use it's byte aligned equivalent. 

For example, with Keil, the default cast to int from a byte aligned
type could (should) be __packed int.

If I cast

(int)buf;

where buf is a byte aligned type, then the compiler could treat it as

(__packed int)buf by default.

Thanks for your help.

Dave S.

--- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@...>
wrote:
>
> 
> 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
> > > >
> > >
> >
>