Re: [ECOS] Network programming for eCos under linux

[Grant Edwards <grante@visi.com>]

On Wed, Aug 08, 2001 at 09:06:06AM -0600, Trenton D. Adams wrote:

>> > AFAICT, that should work on an ARM.  If it doesn't, it is a
>> > compiler bug.
>> 
>> Agreed. It would be different if you were accessing a more
>> strictly aligned type through a less strictly aligned type,
>> e.g. casting a char * to a short
>>
>> * and dereferencing; as Grant says...
> 
> So, you're not supposed to use a "char buffer[1024];" for a generic
> buffer then?  If not, how should one create a generic buffer?

On _some_ platforms (e.g. ARM7) you can't cast an arbitrary
pointer into that buffer to (int*) or (short*) and then
dereference it.  You have to use memcpy() to transfer int or
short values to/from the buffer into actual int or short
objects.

Trust me.  I'm missing several toes from doing things like

   foo(char *p)
     {
     unsigned i;
       [...]
     *((unsigned*)p) = i;
     }

Another fun way to waste an afternoon is to delcare a struct
using __attribute__((packed)).  That is a good way to convince
the compiler to generate code with misaligned accesses that
won't work on some platforms.  I tripped over that many years
ago when I ported code under SunOS from a 68K machine to a
SPARC (the former allowed misaligned accesses, the latter
didn't).

> So, the following gcc parameter would only warn when there is a
> problem with that particular architecture that you're compiling
> for? -Wcast-align
> 
> The one below would make it an error to cast from a char * to
> an int *? -mstrict-align

I don't know the details of how those warnings work.

> So, how would one go about making a buffer word aligned or
> DWORD aligned just to be safe?

You can probably use __attribute__(()) to align the *start* of
the buffer, but if you're copying ints to/from arbitrary
offsets into the buffer, you have to use memcpy() if you want
to be safe/portable.

<soapbox>

I've claimed for many years that C, as a systems language,
should provide a way for the user to specify data layout in
memory when it is require for meeting external requirements
such as memory mapped hardware, comm protocols, etc.  This
would allow the user to control data layout in a static,
declaritive approach, similar to the way C deals with data
types and scoping: all three would be could declared at
compile-time.

The C language mavens reply that C _could_ do something like
that, but they prefer to leave it up to the user to shovel
individual bytes around to get them arranged as desired. (That
way it's much more error prone and uses up more CPU cycles!)
They seem to prefer an imperitive approach, where you layout
data at run-time rather than at compile time, even though
everything else about data objects (type, scope) is defined at
compile time.

I don't understand their reasoning, but there's no way I'm ever
going to convince them to change things now. :)

</soapbox>

-- 
Grant Edwards
grante@visi.com