From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 876 invoked by alias); 26 Mar 2008 20:47:15 -0000 Received: (qmail 866 invoked by uid 22791); 26 Mar 2008 20:47:13 -0000 X-Spam-Check-By: sourceware.org Received: from mgcp1.bloomberg.com (HELO mgcp1.bloomberg.com) (208.22.56.39) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Mar 2008 20:46:56 +0000 Received: from ny1520.bloomberg.com ([10.16.11.97]) by mgcp1.bloomberg.com with ESMTP; 26 Mar 2008 16:46:54 -0400 Received: from NY2528-DR.corp.bloomberg.com (ny2528-dr.corp.bloomberg.com [10.14.21.30]) by ny1520.bloomberg.com (8.14.1/8.14.1) with ESMTP id m2QKkm96026607; Wed, 26 Mar 2008 16:46:48 -0400 Received: from ny2545.corp.bloomberg.com ([172.20.73.98]) by NY2528-DR.corp.bloomberg.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 16:46:48 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Mar 2008 01:53:00 -0000 Message-ID: In-Reply-To: <69dd805e0803261222t77767a69sbed4536df4641929@mail.gmail.com> References: <20080326180616.GA5705@lunn.ch> <20080326181817.GB5705@lunn.ch> <20080326183202.GC5705@lunn.ch> <69dd805e0803261222t77767a69sbed4536df4641929@mail.gmail.com> From: "Chris Zimman" To: "Fabian Scheler" , X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] ARM EABI port / static constructor priority removal X-SW-Source: 2008-03/txt/msg00165.txt.bz2 > just my two cents about that topic - the global objects we are talking > about are singletons, right? So what about something like that >=20 > Cyg_Scheduler* theScheduler() { > static Cyg_Scheduler theScheduler; > return &theScheduler; > } That seems like a viable option. > btw - I have no problem with the init-priority attribute. I believe > that avoiding compiler dependencies is nearly as hard as to be > processor independent. So, for the most OSes provided as source code > the user is supposed to use a specific compiler and with eCos one is > supposed to use gcc eCos is by and large CPU independent. Only a small part of it is processor specific. If you *have* to be compiler specific for some reason, fine. But I can't see a good reason to be just for the sake of it or because of design choices that are fixable. Prior to the ARM EABI work I am doing, you couldn't build CodeSourcery tool chain either, so if you wanted a supported version of GCC w/ eCos you were out of luck. To me, that's a serious drawback for using eCos. We ran into internal compiler errors with GCC 3.4.4 and bad behavior in our application when building with -O2 in some cases. > It is also not possible to compile the linux kernel using the Microsoft Compiler, is it? One thing at a time ;) =20 --Chris -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss