RE: [ECOS] Network programming for eCos under linux

["Trenton D. Adams" <tadams@theone.dnsalias.com>]

Anyhow, thanks to ALL for the input!  I never knew that alignments would
matter.  I knew that on the x86, alignments don't matter and that it
just causes a performance hit if shorts, ints, etc are not accessed on
2, 4, or 8 byte boundaries.  But, since I've never worked on any other
platform other than a PC for programming purposes, I guess I wouldn't
know.  You learn something knew every day! :)

Anyhow, I'll keep that stuff in mind.

  > -----Original Message-----
  > From: ecos-discuss-owner@sources.redhat.com [ mailto:ecos-discuss-
  > owner@sources.redhat.com] On Behalf Of Jonathan Larmour
  > Sent: Wednesday, August 08, 2001 9:14 AM
  > To: Trenton D. Adams
  > Cc: 'Grant Edwards'; 'Andrew Lunn'; 'eCos discussion'
  > Subject: Re: [ECOS] Network programming for eCos under linux
  > 
  > "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?
  > >
  > > So, the following gcc parameter would only warn when there is a
  > problem
  > > with that particular architecture that you're compiling for?
  > > -Wcast-align
  > 
  > Yes, but it would also warn even if you have taken care to ensure it
is
  > aligned.
  > 
  > > The one below would make it an error to cast from a char * to an
int
  > *?
  > > -mstrict-align
  > 
  > Yes.
  > 
  > > So, how would one go about making a buffer word aligned or DWORD
  > aligned
  > > just to be safe?
  > 
  > something along the lines of:
  > 
  > char buffer[1024];
  > #define ALIGNMENT 8
  > #define ALIGNUP(_x_) (((char *)(_x_) + ALIGN-1) & ~(ALIGN-1))
  > int *foo = ALIGNUP(buffer);
  > 
  > You could also use __alignof(int) to give the alignment but that's
  > obviously a GNU C-ism.
  > 
  > >   > > > Maybe i don't have the casts correct.
  > >   > >
  > >   > > There are other casts that are not going to work on ARM
  > >   > > architecture (accessing words on non-word boundaries, for
  > >   > > example).  That's not a compiler error, it's just another
way
  > >   > > to shoot yourself in the foot with C.
  > >   >
  > >   > Although it's worth mentioning that not all architectures
disallow
  > >   > unaligned accesses which is why people think they can get away
  > with
  > > it
  > >   > :).
  > >   >
  > >
  > > This goes back to the -Wcast-align.  If -Wall is on, that means
all
  > > warnings right?
  > 
  > Not all. Look at "info gcc" or "man gcc" to list the warnings that
are
  > and
  > aren't included e.g. -Wcast-align is not included. "man gcc" sez:
  > 
  >       The remaining `-W...' options are not implied by `-Wall'
because
  > they  warn  about
  >        constructions that we consider reasonable to use, on
occasion, in
  > clean programs.
  > 
  > Jifl
  > --
  > Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223)
  > 271062
  > Maybe this world is another planet's Hell -Aldous Huxley ||
  > Opinions==mine