[ECOS] Network programming for eCos under linux

[ECOS] Network programming for eCos under linux

[Trenton D. Adams]

I figured since I couldn't get the i386 target of RedBoot going, I would
ask this question.  I don't really want to waste time on something that
isn't imperative, especially if there's a chance it won't work in the
end.

I was wondering if networking code would be portable between eCos and
Linux?  If there are some minor differences, what are they, and what
#defines would I need to know about in order to do both versions of the
differences and have it compile under both eCos and Linux.

What about multithreading?  Is it similar under Linux?

Trenton D. Adams
Extreme Engineering
#17, 6025 - 12 St. SE
Calgary, Alberta, Canada
T2H 2K1

Phone: 403 640 9494 ext-208
Fax: 403 640 9599

http://www.extremeeng.com

Re: [ECOS] Network programming for eCos under linux

[Andrew Lunn]

> I was wondering if networking code would be portable between eCos and
> Linux?  If there are some minor differences, what are they, and what
> #defines would I need to know about in order to do both versions of the
> differences and have it compile under both eCos and Linux.

I've dones this once. I wrote some code on Linux first, made it work,
and then ported it to eCos. 

#includes are different. eCos just needs <networks.h> where as linux
needs a big collection of include files.

You need to stick to the very basic sockets API. Things like
gethostbyname(), getdomainname() are not implemented on eCos. 

I found some compiler bugs. Code that worked with the plain linux
compiler did not with the arm-elf. These were to do with access to non
aligned memory. 

Watch out for endianness issues. i386 linux is little endian. Whats
the endianness of your target? Things like this affects network code.

The code i was writting was relativly simple and did not need any of
the ecos cyg_* functions. Overall i found it a worth while way of
writing the code. It edit/compile/run/crash cycle is much faster :-)

        Andrew

Re: [ECOS] Network programming for eCos under linux

[Jonathan Larmour]

Andrew Lunn wrote:
> 
> I found some compiler bugs. Code that worked with the plain linux
> compiler did not with the arm-elf. These were to do with access to non
> aligned memory.

I'm not sure this is a compiler bug - I would suspect the linux compiler
can't access non-aligned memory either, but at a guess the kernel catches
the exception and emulates it for you. If that is the case, it's best
avoided as performance would suck.

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

Re: [ECOS] Network programming for eCos under linux

[Andrew Lunn]

> I'm not sure this is a compiler bug - I would suspect the linux compiler
> can't access non-aligned memory either, but at a guess the kernel catches
> the exception and emulates it for you. If that is the case, it's best
> avoided as performance would suck.

I don't remeber the exact details. The code was something like...

static int 
func(char * msg, char * name ; short rr_type) {

 char *ptr;
 int len;
        
 strcpy(msg,name);
 ptr = msg + strlen(name);

 *ptr++ = ((char *)&rr_type)[0];
 *ptr++ = ((char *)&rr_type)[1];
 
 len = ptr - msg;

 return len;
}
 
Maybe i don't have the casts correct. Anyway, i found the ptr was not
being incremented when ptr was not word aligned before the first
*ptr++ operation. This could happen because name can be any length. It
worked fine on i386, but not on arm-elf. To me, this is a compile
bug. I got around it by using shifts and ands instead of casts and
array access.


        Andrew

Re: [ECOS] Network programming for eCos under linux

[Grant Edwards]

On Wed, Aug 08, 2001 at 03:51:17PM +0200, Andrew Lunn wrote:

> > I'm not sure this is a compiler bug - I would suspect the linux
> > compiler can't access non-aligned memory either, but at a guess
> > the kernel catches the exception and emulates it for you. If
> > that is the case, it's best avoided as performance would suck.
> 
> I don't remeber the exact details. The code was something like...
> 
> static int 
> func(char * msg, char * name ; short rr_type) {
> 
>  char *ptr;
>  int len;
>         
>  strcpy(msg,name);
>  ptr = msg + strlen(name);
> 
>  *ptr++ = ((char *)&rr_type)[0];
>  *ptr++ = ((char *)&rr_type)[1];
>  
>  len = ptr - msg;
> 
>  return len;
> }

AFAICT, that should work on an ARM.  If it doesn't, it is a
compiler bug.

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

> Anyway, i found the ptr was not being incremented when ptr was
> not word aligned before the first *ptr++ operation. This could
> happen because name can be any length. It worked fine on i386,
> but not on arm-elf. To me, this is a compile bug. I got around
> it by using shifts and ands instead of casts and array access.

Did you report the bug to the gcc guys?  If it really is a bug,
they'd love to hear about it.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Network programming for eCos under linux

[Jonathan Larmour]

Grant Edwards wrote:
> 
> On Wed, Aug 08, 2001 at 03:51:17PM +0200, Andrew Lunn wrote:
> 
> > > I'm not sure this is a compiler bug - I would suspect the linux
> > > compiler can't access non-aligned memory either, but at a guess
> > > the kernel catches the exception and emulates it for you. If
> > > that is the case, it's best avoided as performance would suck.
> >
> > I don't remeber the exact details. The code was something like...
> >
> > static int
> > func(char * msg, char * name ; short rr_type) {
> >
> >  char *ptr;
> >  int len;
> >
> >  strcpy(msg,name);
> >  ptr = msg + strlen(name);
> >
> >  *ptr++ = ((char *)&rr_type)[0];
> >  *ptr++ = ((char *)&rr_type)[1];
> >
> >  len = ptr - msg;
> >
> >  return len;
> > }
> 
> 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...

> > 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 :).
 
> > Anyway, i found the ptr was not being incremented when ptr was
> > not word aligned before the first *ptr++ operation. This could
> > happen because name can be any length. It worked fine on i386,
> > but not on arm-elf. To me, this is a compile bug. I got around
> > it by using shifts and ands instead of casts and array access.
> 
> Did you report the bug to the gcc guys?  If it really is a bug,
> they'd love to hear about it.

Especially now that the release cycle for gcc 3.0.1 is drawing to a close.

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

RE: [ECOS] Network programming for eCos under linux

[Trenton D. Adams]

  > #includes are different. eCos just needs <networks.h> where as linux
  > needs a big collection of include files.

Yep, I know what to include for a Linux program.

  > 
  > You need to stick to the very basic sockets API. Things like
  > gethostbyname(), getdomainname() are not implemented on eCos.
  > 

Yep, that too! ;)

  > I found some compiler bugs. Code that worked with the plain linux
  > compiler did not with the arm-elf. These were to do with access to
non
  > aligned memory.
  > 

Very weird

  > Watch out for endianness issues. i386 linux is little endian. Whats
  > the endianness of your target? Things like this affects network
code.
  > 

This shouldn't pose a problem since I've configured my ARM as
little-endian.  However, htons (), htonl (), etc should solve that
problem anyhow, shouldn't it?  I mean as far networking code goes that
is.  I would obviously have to be careful about data types between the
two if they were different.  It's nice to have the ARM with 32-bit
little-endian!  Makes my life a lot easier since I'm sending data to a
PC.

  > The code i was writting was relativly simple and did not need any of
  > the ecos cyg_* functions. Overall i found it a worth while way of
  > writing the code. It edit/compile/run/crash cycle is much faster :-)
  > 

I would imagine it is faster using Linux.  


What about threads?  How do those work under Linux?  Are they similar at
all?  

Re: [ECOS] Network programming for eCos under linux

[Andrew Lunn]

> > Did you report the bug to the gcc guys?  If it really is a bug,
> > they'd love to hear about it.
> 
> Especially now that the release cycle for gcc 3.0.1 is drawing to a close.

No i didn't report it. Im trying to reproduce it now, but everything i
try works :-(

        Andrew

RE: [ECOS] Network programming for eCos under linux

[Trenton D. Adams]

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

The one below would make it an error to cast from a char * to an int *?
-mstrict-align

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

  > > > 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?

Re: [ECOS] Network programming for eCos under linux

[Grant Edwards]

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


>   > Watch out for endianness issues. i386 linux is little endian.
>   > Whats the endianness of your target? Things like this affects
>   > network code.
> 
> This shouldn't pose a problem since I've configured my ARM as
> little-endian.  However, htons (), htonl (), etc should solve that
> problem anyhow, shouldn't it?  I mean as far networking code goes that
> is.  I would obviously have to be careful about data types between the
> two if they were different.  It's nice to have the ARM with 32-bit
> little-endian!  Makes my life a lot easier since I'm sending data to a
> PC.

You're headed for trouble.  I work on software where the author
"knew" data was being sent from one little endian machine to
another over the network.  Unfortunately one of the ends is now
big-endian, and it's now a royal PITA to maintain this stuff.
Unfortunalyte there aren't standard host-to-little-endian and
little-endian-to-host macros.

> What about threads?  How do those work under Linux?  Are they similar at
> all?  

The set of mechanisms is similar, but the details are
different. For example, roughly the same set of calls to
synchronize threads exists, but the data types and calling
conventions are different.

If you only use a small set of features, wrapping the Linux
calls to make them look like eCos calls would be a viable
option.  An eCos emulator that runs on top of one of the
popular Unix threading libraries would be an interesting
project.  You couldn't accurately emulate the scheduling
algorithm, but for some applications it could be useful.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] Network programming for eCos under linux

[Trenton D. Adams]

  > 
  > 
  > >   > Watch out for endianness issues. i386 linux is little endian.
  > >   > Whats the endianness of your target? Things like this affects
  > >   > network code.
  > >
  > > This shouldn't pose a problem since I've configured my ARM as
  > > little-endian.  However, htons (), htonl (), etc should solve that
  > > problem anyhow, shouldn't it?  I mean as far networking code goes
that
  > > is.  I would obviously have to be careful about data types between
the
  > > two if they were different.  It's nice to have the ARM with 32-bit
  > > little-endian!  Makes my life a lot easier since I'm sending data
to a
  > > PC.
  > 
  > You're headed for trouble.  I work on software where the author
  > "knew" data was being sent from one little endian machine to
  > another over the network.  Unfortunately one of the ends is now
  > big-endian, and it's now a royal PITA to maintain this stuff.
  > Unfortunalyte there aren't standard host-to-little-endian and
  > little-endian-to-host macros.
  > 
How so?  Are you referring to the networking code, or the data types?

We're not going to be sending to anything other than a PC so either way
it shouldn't be a problem should it?

Re: [ECOS] Network programming for eCos under linux

[Jonathan Larmour]

"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

Re: [ECOS] Network programming for eCos under linux

[Andrew Lunn]

> This shouldn't pose a problem since I've configured my ARM as
> little-endian.  However, htons (), htonl (), etc should solve that
> problem anyhow, shouldn't it?  I mean as far networking code goes that
> is.  I would obviously have to be careful about data types between the
> two if they were different.  It's nice to have the ARM with 32-bit
> little-endian!  Makes my life a lot easier since I'm sending data to a
> PC.

The problem is, if your machines both use the same endianness, you
never know when you have missed out a htons(). If they are different
endianness, it breaks. That why i like to write network code on a
mixed Solaris & linux network, just to make sure.

        Andrew

RE: [ECOS] Network programming for eCos under linux

[Trenton D. Adams]

  > 
  > > This shouldn't pose a problem since I've configured my ARM as
  > > little-endian.  However, htons (), htonl (), etc should solve that
  > > problem anyhow, shouldn't it?  I mean as far networking code goes
that
  > > is.  I would obviously have to be careful about data types between
the
  > > two if they were different.  It's nice to have the ARM with 32-bit
  > > little-endian!  Makes my life a lot easier since I'm sending data
to a
  > > PC.
  > 
  > The problem is, if your machines both use the same endianness, you
  > never know when you have missed out a htons(). If they are different
  > endianness, it breaks. That why i like to write network code on a
  > mixed Solaris & linux network, just to make sure.
  > 
If you miss an htons () though, your program won't work anyhow if you're
on a little-endian architecture.  Take for instance watching on port 10.
If you don't do an htons () to convert to network byte order (BIG
ENDIAN), then your program would watch on port 2560 instead of 10.

Re: [ECOS] Network programming for eCos under linux

[Grant Edwards]

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

Re: [ECOS] Network programming for eCos under linux

[Grant Edwards]

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

>> > > Watch out for endianness issues. i386 linux is little endian.
>> > > Whats the endianness of your target? Things like this affects
>> > > network code.
>> >
>> > This shouldn't pose a problem since I've configured my ARM as
>> > little-endian.  However, htons (), htonl (), etc should solve
>> > that problem anyhow, shouldn't it?  I mean as far networking
>> > code goes that is.  I would obviously have to be careful about
>> > data types between the two if they were different.  It's nice
>> > to have the ARM with 32-bit little-endian!  Makes my life a lot
>> > easier since I'm sending data to a PC.
>> 
>> You're headed for trouble.  I work on software where the author
>> "knew" data was being sent from one little endian machine to
>> another over the network.  Unfortunately one of the ends is now
>> big-endian, and it's now a royal PITA to maintain this stuff.
>> Unfortunalyte there aren't standard host-to-little-endian and
>> little-endian-to-host macros.
>
> How so?  Are you referring to the networking code, or the data
> types?

Application data.

> We're not going to be sending to anything other than a PC so
> either way it shouldn't be a problem should it?

Just like the code I'm working on would never be sending to
anything other than an x86.  Except the x86-based box has been
replaced by a big-endian ARM box.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] Network programming for eCos under linux

[Trenton D. Adams]

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

Well apparently Microsoft's compiler doesn't follow the standard then!
Oh, that's a big surprise!!!! ;) LMAO.  Anyhow, it allows you to specify
alignment for compile time.  I would have to say that in this case, I
agree with Microsoft not following the standard! :) 

RE: [ECOS] Network programming for eCos under linux

[Trenton D. Adams]

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

[ECOS] Re: Network programming for eCos under linux

[Grant Edwards]

Trenton D. Adams writes:

>   > <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>
>   >  
> 
> Well apparently Microsoft's compiler doesn't follow the standard then!
> Oh, that's a big surprise!!!! ;) LMAO.  Anyhow, it allows you to specify
> alignment for compile time.  I would have to say that in this case, I
> agree with Microsoft not following the standard! :)  
>

Gcc does let you partially specify alignment/packing: AFAIK, qthere's no way 
to prevent it from padding the end of the struct.  But, it won't
generate guaranteed valid instruction sequences when you access the fields.  
If you could at least prevent the padding, you could use fields
as targets for memcpy() operations, but the padding prevents that from
being a usable option. 

[Apologies for message formatting problems. My Cisco 675 just locked up 
again (third time this week). I have to use a web-mail interface until
I can get home and cycle power on the stupid thing.  I guess it's time
to try upgrading the flash...]
-- 
Grant Edwards
grante@visi.com 

RE: [ECOS] Network programming for eCos under linux

[Trenton D. Adams]

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

First of all, I assume your ALIGN is actually supposed to be ALIGNMENT!

I don't understand your macro.  Let's say _x_ happens to be memory
address 0x201 the macro formula would go like this

= (0x201 + 7) & ~(7)
= 0x208 & 0xfffffff8
= 0x208

So, now foo is pointing to an integer that is not at the beginning of
the buffer.  This would mean that I couldn't put anything at the
beginning of the buffer, correct?

[ECOS] Re: Network programming for eCos under linux

[Grant Edwards]

Andrew Lunn writes:

>> This shouldn't pose a problem since I've configured my ARM as
>> little-endian.  However, htons (), htonl (), etc should solve that
>> problem anyhow, shouldn't it?  I mean as far networking code goes that
>> is.  I would obviously have to be careful about data types between the
>> two if they were different.  It's nice to have the ARM with 32-bit
>> little-endian!  Makes my life a lot easier since I'm sending data to a
>> PC.
> 
> The problem is, if your machines both use the same endianness, you
> never know when you have missed out a htons(). If they are different
> endianness, it breaks. That why i like to write network code on a
> mixed Solaris & linux network, just to make sure. 
>

Pedant mode on... 

Stricly speaking, it doesn't matter whether you're running Solaris or
Linux.  Both are BE on SPARC and LE on IA32.  What you want is a mixed
SPARC & IA32 setup.  That said, if you pick a Linux machine at random 
there's probably a 99+ percent chance it's IA32 -- and if you pick a Solaris 
machine at random there's a 99+ percent chance it's SPARC. 

-- 
Grant Edwards
grante@visi.com 

Re: [ECOS] Network programming for eCos under linux

[Mark Salter]

>>>>> Trenton D Adams writes:

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

> First of all, I assume your ALIGN is actually supposed to be ALIGNMENT!

> I don't understand your macro.  Let's say _x_ happens to be memory
> address 0x201 the macro formula would go like this

> = (0x201 + 7) & ~(7)
> = 0x208 & 0xfffffff8
> = 0x208

> So, now foo is pointing to an integer that is not at the beginning of
> the buffer.  This would mean that I couldn't put anything at the
> beginning of the buffer, correct?

How about this (assuming you need integer alignment):

  int aligned_buffer[1024/sizeof(int)];
  char *buffer = (char *)&aligned_buffer;

--Mark

Re: [ECOS] Network programming for eCos under linux

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
>   >
>   > > 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.
>   >
> 
> First of all, I assume your ALIGN is actually supposed to be ALIGNMENT!

Oops yes.
 
> I don't understand your macro.  Let's say _x_ happens to be memory
> address 0x201 the macro formula would go like this
> 
> = (0x201 + 7) & ~(7)
> = 0x208 & 0xfffffff8
> = 0x208
> 
> So, now foo is pointing to an integer that is not at the beginning of
> the buffer.  This would mean that I couldn't put anything at the
> beginning of the buffer, correct?

If 8 byte alignment was the requirement then you certainly wouldn't want
to. I suppose in that case you would make the buffer be 1031 bytes to
ensure it could fit 1024 bytes post alignment.

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

[ECOS] Re: Network programming for eCos under linux

[Grant Edwards]

Trenton D. Adams writes:

>   > 
>   > > 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.
>   >  
> 
> First of all, I assume your ALIGN is actually supposed to be ALIGNMENT! 
> 
> I don't understand your macro.  Let's say _x_ happens to be memory
> address 0x201 the macro formula would go like this 
> 
> = (0x201 + 7) & ~(7)
> = 0x208 & 0xfffffff8
> = 0x208 
> 
> So, now foo is pointing to an integer that is not at the beginning of
> the buffer.  This would mean that I couldn't put anything at the
> beginning of the buffer, correct?

Not by dereferenceing a short or int pointer.  You've got to use memcpy(). 

-- 
Grant Edwards
grante@visi.com 

[ECOS] Re: Network programming for eCos under linux

[Grant Edwards]

Jonathan Larmour writes:

> "Trenton D. Adams" wrote:
>> 
>>   >
>>   > > 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.
>>   > 
>> 
>> First of all, I assume your ALIGN is actually supposed to be ALIGNMENT!
> 
> Oops yes.
>  
>> I don't understand your macro.  Let's say _x_ happens to be memory
>> address 0x201 the macro formula would go like this 
>> 
>> = (0x201 + 7) & ~(7)
>> = 0x208 & 0xfffffff8
>> = 0x208 
>> 
>> So, now foo is pointing to an integer that is not at the beginning of
>> the buffer.  This would mean that I couldn't put anything at the
>> beginning of the buffer, correct?
> 
> If 8 byte alignment was the requirement then you certainly wouldn't want
> to. I suppose in that case you would make the buffer be 1031 bytes to
> ensure it could fit 1024 bytes post alignment.

Yup -- but that only fixes the problem at the start of the buffer or
if you're using an array of homogeneously sized data objects. 

If you're filling the buffer with a collection of packed, hetrogenous
data objects, you'll run into alignment problems somewhere else
in the buffer. 

-- 
Grant Edwards
grante@visi.com