* [ECOS] Network programming for eCos under linux @ 2001-08-07 15:41 Trenton D. Adams 2001-08-08 0:35 ` Andrew Lunn 0 siblings, 1 reply; 25+ messages in thread From: Trenton D. Adams @ 2001-08-07 15:41 UTC (permalink / raw) To: 'eCos Discussion' 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-07 15:41 [ECOS] Network programming for eCos under linux Trenton D. Adams @ 2001-08-08 0:35 ` Andrew Lunn 2001-08-08 6:27 ` Jonathan Larmour 2001-08-08 7:57 ` [ECOS] " Trenton D. Adams 0 siblings, 2 replies; 25+ messages in thread From: Andrew Lunn @ 2001-08-08 0:35 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'eCos Discussion' > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-08 0:35 ` Andrew Lunn @ 2001-08-08 6:27 ` Jonathan Larmour 2001-08-08 6:51 ` Andrew Lunn 2001-08-08 7:57 ` [ECOS] " Trenton D. Adams 1 sibling, 1 reply; 25+ messages in thread From: Jonathan Larmour @ 2001-08-08 6:27 UTC (permalink / raw) To: Andrew Lunn; +Cc: Trenton D. Adams, 'eCos Discussion' 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-08 6:27 ` Jonathan Larmour @ 2001-08-08 6:51 ` Andrew Lunn 2001-08-08 7:13 ` Grant Edwards 0 siblings, 1 reply; 25+ messages in thread From: Andrew Lunn @ 2001-08-08 6:51 UTC (permalink / raw) To: Jonathan Larmour; +Cc: Andrew Lunn, Trenton D. Adams, 'eCos Discussion' > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-08 6:51 ` Andrew Lunn @ 2001-08-08 7:13 ` Grant Edwards 2001-08-08 7:52 ` Jonathan Larmour 0 siblings, 1 reply; 25+ messages in thread From: Grant Edwards @ 2001-08-08 7:13 UTC (permalink / raw) To: Jonathan Larmour, Andrew Lunn, Trenton D. Adams, 'eCos Discussion' 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-08 7:13 ` Grant Edwards @ 2001-08-08 7:52 ` Jonathan Larmour 2001-08-08 8:02 ` Andrew Lunn 2001-08-08 8:06 ` Trenton D. Adams 0 siblings, 2 replies; 25+ messages in thread From: Jonathan Larmour @ 2001-08-08 7:52 UTC (permalink / raw) To: Grant Edwards; +Cc: Andrew Lunn, eCos discussion 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-08 7:52 ` Jonathan Larmour @ 2001-08-08 8:02 ` Andrew Lunn 2001-08-08 8:06 ` Trenton D. Adams 1 sibling, 0 replies; 25+ messages in thread From: Andrew Lunn @ 2001-08-08 8:02 UTC (permalink / raw) To: Jonathan Larmour; +Cc: Grant Edwards, Andrew Lunn, eCos discussion > > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] Network programming for eCos under linux 2001-08-08 7:52 ` Jonathan Larmour 2001-08-08 8:02 ` Andrew Lunn @ 2001-08-08 8:06 ` Trenton D. Adams 2001-08-08 8:14 ` Jonathan Larmour 2001-08-08 8:32 ` [ECOS] " Grant Edwards 1 sibling, 2 replies; 25+ messages in thread From: Trenton D. Adams @ 2001-08-08 8:06 UTC (permalink / raw) To: 'Jonathan Larmour', 'Grant Edwards' Cc: 'Andrew Lunn', 'eCos discussion' > > > > 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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-08 8:06 ` Trenton D. Adams @ 2001-08-08 8:14 ` Jonathan Larmour 2001-08-08 8:47 ` Trenton D. Adams 2001-08-08 8:58 ` Trenton D. Adams 2001-08-08 8:32 ` [ECOS] " Grant Edwards 1 sibling, 2 replies; 25+ messages in thread From: Jonathan Larmour @ 2001-08-08 8:14 UTC (permalink / raw) To: Trenton D. Adams Cc: 'Grant Edwards', 'Andrew Lunn', 'eCos discussion' "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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] Network programming for eCos under linux 2001-08-08 8:14 ` Jonathan Larmour @ 2001-08-08 8:47 ` Trenton D. Adams 2001-08-08 8:58 ` Trenton D. Adams 1 sibling, 0 replies; 25+ messages in thread From: Trenton D. Adams @ 2001-08-08 8:47 UTC (permalink / raw) To: 'Jonathan Larmour' Cc: 'Grant Edwards', 'Andrew Lunn', 'eCos discussion' 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] Network programming for eCos under linux 2001-08-08 8:14 ` Jonathan Larmour 2001-08-08 8:47 ` Trenton D. Adams @ 2001-08-08 8:58 ` Trenton D. Adams 2001-08-08 9:04 ` Mark Salter ` (2 more replies) 1 sibling, 3 replies; 25+ messages in thread From: Trenton D. Adams @ 2001-08-08 8:58 UTC (permalink / raw) To: 'Jonathan Larmour' Cc: 'Grant Edwards', 'Andrew Lunn', 'eCos discussion' > > > 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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-08 8:58 ` Trenton D. Adams @ 2001-08-08 9:04 ` Mark Salter 2001-08-08 9:06 ` Jonathan Larmour 2001-08-08 9:07 ` Grant Edwards 2 siblings, 0 replies; 25+ messages in thread From: Mark Salter @ 2001-08-08 9:04 UTC (permalink / raw) To: tadams; +Cc: jlarmour, grante, andrew.lunn, ecos-discuss >>>>> 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-08 8:58 ` Trenton D. Adams 2001-08-08 9:04 ` Mark Salter @ 2001-08-08 9:06 ` Jonathan Larmour 2001-08-08 9:19 ` [ECOS] " Grant Edwards 2001-08-08 9:07 ` Grant Edwards 2 siblings, 1 reply; 25+ messages in thread From: Jonathan Larmour @ 2001-08-08 9:06 UTC (permalink / raw) To: Trenton D. Adams Cc: 'Grant Edwards', 'Andrew Lunn', 'eCos discussion' "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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ECOS] Re: Network programming for eCos under linux 2001-08-08 9:06 ` Jonathan Larmour @ 2001-08-08 9:19 ` Grant Edwards 0 siblings, 0 replies; 25+ messages in thread From: Grant Edwards @ 2001-08-08 9:19 UTC (permalink / raw) To: Jonathan Larmour Cc: Trenton D. Adams, 'Andrew Lunn', 'eCos discussion' 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ECOS] Re: Network programming for eCos under linux 2001-08-08 8:58 ` Trenton D. Adams 2001-08-08 9:04 ` Mark Salter 2001-08-08 9:06 ` Jonathan Larmour @ 2001-08-08 9:07 ` Grant Edwards 2 siblings, 0 replies; 25+ messages in thread From: Grant Edwards @ 2001-08-08 9:07 UTC (permalink / raw) To: Trenton D. Adams Cc: 'Jonathan Larmour', 'Andrew Lunn', 'eCos discussion' 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-08 8:06 ` Trenton D. Adams 2001-08-08 8:14 ` Jonathan Larmour @ 2001-08-08 8:32 ` Grant Edwards 2001-08-08 8:43 ` Trenton D. Adams 1 sibling, 1 reply; 25+ messages in thread From: Grant Edwards @ 2001-08-08 8:32 UTC (permalink / raw) To: Trenton D. Adams Cc: 'Jonathan Larmour', 'Andrew Lunn', 'eCos discussion' 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] Network programming for eCos under linux 2001-08-08 8:32 ` [ECOS] " Grant Edwards @ 2001-08-08 8:43 ` Trenton D. Adams 2001-08-08 8:57 ` [ECOS] " Grant Edwards 0 siblings, 1 reply; 25+ messages in thread From: Trenton D. Adams @ 2001-08-08 8:43 UTC (permalink / raw) To: 'Grant Edwards' Cc: 'Jonathan Larmour', 'Andrew Lunn', 'eCos discussion' > <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! :) ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ECOS] Re: Network programming for eCos under linux 2001-08-08 8:43 ` Trenton D. Adams @ 2001-08-08 8:57 ` Grant Edwards 0 siblings, 0 replies; 25+ messages in thread From: Grant Edwards @ 2001-08-08 8:57 UTC (permalink / raw) To: Trenton D. Adams Cc: 'Jonathan Larmour', 'Andrew Lunn', 'eCos discussion' 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] Network programming for eCos under linux 2001-08-08 0:35 ` Andrew Lunn 2001-08-08 6:27 ` Jonathan Larmour @ 2001-08-08 7:57 ` Trenton D. Adams 2001-08-08 8:09 ` Grant Edwards 2001-08-08 8:21 ` Andrew Lunn 1 sibling, 2 replies; 25+ messages in thread From: Trenton D. Adams @ 2001-08-08 7:57 UTC (permalink / raw) To: 'Andrew Lunn'; +Cc: 'eCos Discussion' > #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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-08 7:57 ` [ECOS] " Trenton D. Adams @ 2001-08-08 8:09 ` Grant Edwards 2001-08-08 8:14 ` Trenton D. Adams 2001-08-08 8:21 ` Andrew Lunn 1 sibling, 1 reply; 25+ messages in thread From: Grant Edwards @ 2001-08-08 8:09 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'Andrew Lunn', 'eCos Discussion' 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] Network programming for eCos under linux 2001-08-08 8:09 ` Grant Edwards @ 2001-08-08 8:14 ` Trenton D. Adams 2001-08-08 8:42 ` Grant Edwards 0 siblings, 1 reply; 25+ messages in thread From: Trenton D. Adams @ 2001-08-08 8:14 UTC (permalink / raw) To: 'Grant Edwards'; +Cc: 'Andrew Lunn', 'eCos Discussion' > > > > > 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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-08 8:14 ` Trenton D. Adams @ 2001-08-08 8:42 ` Grant Edwards 0 siblings, 0 replies; 25+ messages in thread From: Grant Edwards @ 2001-08-08 8:42 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'Andrew Lunn', 'eCos Discussion' 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] Network programming for eCos under linux 2001-08-08 7:57 ` [ECOS] " Trenton D. Adams 2001-08-08 8:09 ` Grant Edwards @ 2001-08-08 8:21 ` Andrew Lunn 2001-08-08 8:27 ` Trenton D. Adams 2001-08-08 9:00 ` [ECOS] " Grant Edwards 1 sibling, 2 replies; 25+ messages in thread From: Andrew Lunn @ 2001-08-08 8:21 UTC (permalink / raw) To: Trenton D. Adams; +Cc: eCos Disuss > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] Network programming for eCos under linux 2001-08-08 8:21 ` Andrew Lunn @ 2001-08-08 8:27 ` Trenton D. Adams 2001-08-08 9:00 ` [ECOS] " Grant Edwards 1 sibling, 0 replies; 25+ messages in thread From: Trenton D. Adams @ 2001-08-08 8:27 UTC (permalink / raw) To: 'Andrew Lunn'; +Cc: 'eCos Disuss' > > > 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ECOS] Re: Network programming for eCos under linux 2001-08-08 8:21 ` Andrew Lunn 2001-08-08 8:27 ` Trenton D. Adams @ 2001-08-08 9:00 ` Grant Edwards 1 sibling, 0 replies; 25+ messages in thread From: Grant Edwards @ 2001-08-08 9:00 UTC (permalink / raw) To: Andrew Lunn; +Cc: Trenton D. Adams, eCos Disuss 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2001-08-08 9:19 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-08-07 15:41 [ECOS] Network programming for eCos under linux Trenton D. Adams 2001-08-08 0:35 ` Andrew Lunn 2001-08-08 6:27 ` Jonathan Larmour 2001-08-08 6:51 ` Andrew Lunn 2001-08-08 7:13 ` Grant Edwards 2001-08-08 7:52 ` Jonathan Larmour 2001-08-08 8:02 ` Andrew Lunn 2001-08-08 8:06 ` Trenton D. Adams 2001-08-08 8:14 ` Jonathan Larmour 2001-08-08 8:47 ` Trenton D. Adams 2001-08-08 8:58 ` Trenton D. Adams 2001-08-08 9:04 ` Mark Salter 2001-08-08 9:06 ` Jonathan Larmour 2001-08-08 9:19 ` [ECOS] " Grant Edwards 2001-08-08 9:07 ` Grant Edwards 2001-08-08 8:32 ` [ECOS] " Grant Edwards 2001-08-08 8:43 ` Trenton D. Adams 2001-08-08 8:57 ` [ECOS] " Grant Edwards 2001-08-08 7:57 ` [ECOS] " Trenton D. Adams 2001-08-08 8:09 ` Grant Edwards 2001-08-08 8:14 ` Trenton D. Adams 2001-08-08 8:42 ` Grant Edwards 2001-08-08 8:21 ` Andrew Lunn 2001-08-08 8:27 ` Trenton D. Adams 2001-08-08 9:00 ` [ECOS] " Grant Edwards
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).