From owner-freebsd-platforms Fri Aug 18 2:35: 2 2000 Delivered-To: freebsd-platforms@freebsd.org Received: from gw.capgemini.fr (gw.capgemini.fr [194.3.247.254]) by hub.freebsd.org (Postfix) with ESMTP id 215EF37B422 for ; Fri, 18 Aug 2000 02:34:59 -0700 (PDT) Received: from prenoms.capgemini.fr (capmail.capgemini.fr [194.2.91.200]) by gw.capgemini.fr (8.9.3/8.9.1) with ESMTP id LAA10869 for ; Fri, 18 Aug 2000 11:34:50 +0200 (MET DST) Received: from prenoms.capgemini.fr (localhost [127.0.0.1]) by prenoms.capgemini.fr (8.9.3/8.9.3) with ESMTP id LAA02306; Fri, 18 Aug 2000 11:34:52 +0200 (MET DST) Received: from capgemini.fr ([194.3.238.81]) by prenoms.capgemini.fr (8.9.3/8.9.3) with ESMTP id LAA02292; Fri, 18 Aug 2000 11:34:52 +0200 (MET DST) Message-ID: <399D02FC.BEAC8D98@capgemini.fr> Date: Fri, 18 Aug 2000 11:33:48 +0200 From: Bruno BEC X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-platforms@FreeBSD.ORG Subject: compile FreeBSD with ANSI compiler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-platforms@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, In order to have better performances on a new platform we intend to compile FreeBSD with a specific ANSI-C compliant compiler instead of gcc. We made the same experience with the Linux Kernel and had bad surprises due to significant non ANSI code souce (this code is not rejected by gcc which is not fully ANSI-C). Did one of you have any experience or information about the ANSI compliance of the FreeBSD kernel ? Thanks Bruno -- Bruno BEC Project Leader CAP GEMINI ERNST & YOUNG division ITMI - Technical Computing 485, avenue de l' Europe Montbonnot 38334 Saint Ismier Cedex Tel : +33 (0)4 76 52 62 00 Direct : +33 (0)4 76 52 66 59 Fax : +33 (0)4 76 52 62 01 E-Mail : bbec@capgemini.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-platforms" in the body of the message From owner-freebsd-platforms Fri Aug 18 2:40:56 2000 Delivered-To: freebsd-platforms@freebsd.org Received: from gw.capgemini.fr (gw.capgemini.fr [194.3.247.254]) by hub.freebsd.org (Postfix) with ESMTP id 0DAEE37B423 for ; Fri, 18 Aug 2000 02:40:54 -0700 (PDT) Received: from prenoms.capgemini.fr (capmail.capgemini.fr [194.2.91.200]) by gw.capgemini.fr (8.9.3/8.9.1) with ESMTP id LAA12318 for ; Fri, 18 Aug 2000 11:40:49 +0200 (MET DST) Received: from prenoms.capgemini.fr (localhost [127.0.0.1]) by prenoms.capgemini.fr (8.9.3/8.9.3) with ESMTP id LAA11077 for ; Fri, 18 Aug 2000 11:40:52 +0200 (MET DST) Received: from capgemini.fr ([194.3.238.81]) by prenoms.capgemini.fr (8.9.3/8.9.3) with ESMTP id LAA11063 for ; Fri, 18 Aug 2000 11:40:51 +0200 (MET DST) Message-ID: <399D0464.4ED01D1B@capgemini.fr> Date: Fri, 18 Aug 2000 11:39:48 +0200 From: Bruno BEC X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-platforms@FreeBSD.ORG Subject: Port FreeBSD on new processor Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-platforms@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, We perform a comparative analysis between Linux (UClinux) and FreeBSD for a customer who want to port the OS and the whole dev. chain (gdb, gcc) on a new RISC/DSP processor for embedded applications. 1) I am looking for pro/cons or performances comparison between these both OS, especially the TCP/IP perf. Some idea ? 2) Our customer's application would require a real-time version of the OS (RTLinux, UCLinux ..). Do you know if such a patch does exist for FreeBSD ? 3)Is their anybody who already port FreeBSD on MMU-less Risc/DSP platforms ? Thanks in advance Regards Bruno -- Bruno BEC Project Leader CAP GEMINI ERNST & YOUNG division ITMI - Technical Computing 485, avenue de l' Europe Montbonnot 38334 Saint Ismier Cedex Tel : +33 (0)4 76 52 62 00 Direct : +33 (0)4 76 52 66 59 Fax : +33 (0)4 76 52 62 01 E-Mail : bbec@capgemini.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-platforms" in the body of the message From owner-freebsd-platforms Fri Aug 18 5:30:32 2000 Delivered-To: freebsd-platforms@freebsd.org Received: from gw.capgemini.fr (gw.capgemini.fr [194.3.247.254]) by hub.freebsd.org (Postfix) with ESMTP id 189F937B422 for ; Fri, 18 Aug 2000 05:30:30 -0700 (PDT) Received: from prenoms.capgemini.fr (capmail.capgemini.fr [194.2.91.200]) by gw.capgemini.fr (8.9.3/8.9.1) with ESMTP id OAA12860 for ; Fri, 18 Aug 2000 14:30:25 +0200 (MET DST) Received: from prenoms.capgemini.fr (localhost [127.0.0.1]) by prenoms.capgemini.fr (8.9.3/8.9.3) with ESMTP id OAA05902 for ; Fri, 18 Aug 2000 14:30:28 +0200 (MET DST) Received: from capgemini.fr ([194.3.238.81]) by prenoms.capgemini.fr (8.9.3/8.9.3) with ESMTP id OAA05882 for ; Fri, 18 Aug 2000 14:30:27 +0200 (MET DST) Message-ID: <399D2C24.CFABF66@capgemini.fr> Date: Fri, 18 Aug 2000 14:29:24 +0200 From: Bruno BEC X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freeBSD platforms Subject: FreeBSD and ANSI compiler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-platforms@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, In order to have better performances on a new platform we intend to compile FreeBSD with a specific ANSI-C compliant compiler instead of gcc. We made the same experience with the Linux Kernel and had bad surprises due to significant non ANSI code souce (this code is not rejected by gcc which is not fully ANSI-C). Did one of you have any experience or information about the ANSI compliance of the FreeBSD kernel ? Thanks Bruno -- Bruno BEC Project Leader CAP GEMINI ERNST & YOUNG division ITMI - Technical Computing 485, avenue de l' Europe Montbonnot 38334 Saint Ismier Cedex Tel : +33 (0)4 76 52 62 00 Direct : +33 (0)4 76 52 66 59 Fax : +33 (0)4 76 52 62 01 E-Mail : bbec@capgemini.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-platforms" in the body of the message From owner-freebsd-platforms Fri Aug 18 5:37:21 2000 Delivered-To: freebsd-platforms@freebsd.org Received: from ns.triplan.com (ns.triplan.com [62.159.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 9DCE137B423 for ; Fri, 18 Aug 2000 05:37:17 -0700 (PDT) Received: from hermes.triplan.com (root@hermes.net.triplan.com [192.168.1.6]) by ns.triplan.com (8.9.3/8.9.3) with ESMTP id OAA25309; Fri, 18 Aug 2000 14:37:15 +0200 Received: from triplan.com (chuck.sup.bs.triplan.com [192.168.1.158]) by hermes.triplan.com (8.9.3/8.9.3) with ESMTP id OAA31182; Fri, 18 Aug 2000 14:37:15 +0200 Message-ID: <399D2DFB.7947E7@triplan.com> Date: Fri, 18 Aug 2000 14:37:15 +0200 From: Karl Dietz X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de,es MIME-Version: 1.0 To: Bruno BEC Cc: freebsd-platforms@FreeBSD.ORG Subject: Re: Port FreeBSD on new processor References: <399D0464.4ED01D1B@capgemini.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-platforms@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bruno BEC wrote: > > Hi all, > > We perform a comparative analysis between Linux (UClinux) and FreeBSD > for a > customer who want to port the OS and the whole dev. chain (gdb, gcc) on > a new > RISC/DSP processor for embedded applications. > > 1) I am looking for pro/cons or performances comparison between these > both OS, > especially the TCP/IP perf. Some idea ? Have a look a the common BSD vs. Linux papers placed all over the web. BSD's TCP/IP stack has been better than Linux's in terms of performance and stability in the past, I can't say if this is still the case. > 2) Our customer's application would require a real-time version of the > OS > (RTLinux, UCLinux ..). Do you know if such a patch does exist for > FreeBSD ? > > 3)Is their anybody who already port FreeBSD on MMU-less Risc/DSP > platforms ? Not to my knowledge, but you might have a look at NetBSD IIRC it has been ported to a MMU-less system already, but I'm not sure. -- mfG Karl Dietz Netzwerk & Systeme To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-platforms" in the body of the message From owner-freebsd-platforms Fri Aug 18 14:47:44 2000 Delivered-To: freebsd-platforms@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 3B2CB37B422 for ; Fri, 18 Aug 2000 14:47:37 -0700 (PDT) Received: (qmail 23313 invoked from network); 18 Aug 2000 21:47:31 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 18 Aug 2000 21:47:31 -0000 Date: Sat, 19 Aug 2000 07:47:26 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Bruno BEC Cc: freebsd-platforms@FreeBSD.ORG Subject: Re: compile FreeBSD with ANSI compiler In-Reply-To: <399D02FC.BEAC8D98@capgemini.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-platforms@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 18 Aug 2000, Bruno BEC wrote: > Hi all, > > In order to have better performances on a new platform we intend to > compile FreeBSD with a specific ANSI-C compliant compiler instead of > gcc. > We made the same experience with the Linux Kernel and had bad surprises > due to significant non ANSI code souce (this code is not rejected by gcc > > which is not fully ANSI-C). > > Did one of you have any experience or information about the ANSI > compliance of the FreeBSD kernel ? It is similar to Linux -- very non-conformant. Last November, compiling LINT with 'gcc -pedantic -ansi ...' gave 14064 lines of warnings after removal of 50000 (?) lines of duplicated warnings for machine-generated code in . That's with gcc'isms like __inline and __attribute__((__packed__) (ick) accepted without warnings. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-platforms" in the body of the message From owner-freebsd-platforms Fri Aug 18 19: 9:33 2000 Delivered-To: freebsd-platforms@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 8F6C837B422 for ; Fri, 18 Aug 2000 19:09:29 -0700 (PDT) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id TAA04855; Fri, 18 Aug 2000 19:09:31 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAeaaOAj; Fri Aug 18 19:09:21 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id TAA01146; Fri, 18 Aug 2000 19:09:16 -0700 (MST) From: Terry Lambert Message-Id: <200008190209.TAA01146@usr08.primenet.com> Subject: Re: FreeBSD and ANSI compiler To: bbec@capgemini.fr (Bruno BEC) Date: Sat, 19 Aug 2000 02:09:16 +0000 (GMT) Cc: freebsd-platforms@FreeBSD.ORG (freeBSD platforms) In-Reply-To: <399D2C24.CFABF66@capgemini.fr> from "Bruno BEC" at Aug 18, 2000 02:29:24 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-platforms@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In order to have better performances on a new platform we intend to > compile FreeBSD with a specific ANSI-C compliant compiler instead of > gcc. > We made the same experience with the Linux Kernel and had bad surprises > due to significant non ANSI code souce (this code is not rejected by gcc > > which is not fully ANSI-C). > > Did one of you have any experience or information about the ANSI > compliance of the FreeBSD kernel ? Here's what I ran into trying to use TenDRA, the several times I tried it... FreeBSD uses: o inline assembly functions (obvious reasons) __asm__(".weak alias"); o linker sets (a cheat to make the linker create a list of structs from individual structs in a bunch of object files. This lets you decide at link time, rather than at compile time, whether or not you will include a module in a list of modules, in which a particular module is dereferenced through a pointer in a struct. This is an overload of the C++ virtual base class initialization functions, which use linker sets to aggregate the constructors to get them callled at runtime. #ifdef __alpha__ #define MAKE_SET(set, sym) \ static void const * const __set_##set##_sym_##sym = &sym; \ __asm(".align 3"); \ __asm(".section .set." #set ",\"aw\""); \ __asm(".quad " #sym); \ __asm(".previous") #else #define MAKE_SET(set, sym) \ static void const * const __set_##set##_sym_##sym = &sym; \ __asm(".section .set." #set ",\"aw\""); \ __asm(".long " #sym); \ __asm(".previous") #endif o variant array indices (one place that I remember, which may have already been fixed; this sort of thing is really pretty inexcusable). foo( int i) { char array[ i]; ... } o #pragma pack (this is for strucutre packing for byte alignment in structures; some compilers like to be "efficient" for access, which make them impossible to use to directly map structures to hardware memory mapped data; this forces them to pack on particular byte boundaries). #pragma pack(1) struct dohickey { unsigned int abyte:8; unsigned int aword:16; unsigned int abyte:8; ... }; o K&R style declatations for functions, with prototypes of whatever the compiler prefers (e.g. tests for ANSI and C++ and uses them if the answer is yes). void fee( int i, char c); void fee( i, c) int i; char c; { ... } o Some newer code uses ANSI prototypes on function declarations (this means that if you have a compiler that likes strictly one mode or the other, or you have a K&R compiler, you are pretty much screwed. void fum( int i, char c); void fum( int i, char c) { ... } Other than that; it's pretty clean, as these things go. It would be nice if someone would comb out the remaining rats, like the ANSI C prototypes in functions, the inline assembly, and the variant array indices. Linker sets would require an object post-processor that created a data-only onlject from input object files that had the data stored as text with magic bytes (e.g. like how the "what" command works on extracting ids). The inline assembly would be hard to remove entirely, but it should perhaps be isolated in seperate platform dependent source files and/or include files, to allow a variant inline vs. external assembly file usage. At the very least, C versions of everything for which C versions are at all possible, should be provided. I think the variant array indices, if they exist, really need to go: they are so GNU dependant that they have no hope. Hope this helps... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-platforms" in the body of the message