From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6387 invoked by alias); 20 May 2005 10:44:57 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 6050 invoked from network); 20 May 2005 10:44:30 -0000 Received: from unknown (HELO smtp.ecoscentric.com) (194.153.168.165) by sourceware.org with SMTP; 20 May 2005 10:44:30 -0000 Received: by smtp.ecoscentric.com (Postfix, from userid 99) id 1C3BA65C0B8; Fri, 20 May 2005 11:44:30 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by smtp.ecoscentric.com (Postfix) with ESMTP id 927AA65C064; Fri, 20 May 2005 11:44:28 +0100 (BST) Message-ID: <428DBF8C.1050409@jifvik.org> Date: Sat, 21 May 2005 08:30:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) MIME-Version: 1.0 To: Jerome Souquieres Cc: eCos Discussion References: <1116574872.10422.23.camel@localhost.locald omain> <428DB2AB.10106@kis.fr> In-Reply-To: <428DB2AB.10106@kis.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [ECOS] Re: C++ Support X-SW-Source: 2005-05/txt/msg00281.txt.bz2 Jerome Souquieres wrote: > Øyvind Harboe wrote: > >> http://www.zylin.com/libstdc++.html >> http://www.zylin.com/stlport.html >> >> For the libstdc++ stuff I submitted a patch to eCos w.r.t. some issues >> with using C++ early in eCos startup, but it didn't receive any comments >> so far: >> >> > Hi, > > I am currently investigating myself about eCos, GCC and C++. I've > read your instructions in the URL mentioned above, which were quite > interesting and I see that you are using eCos pthreads compatibility > layer to make gcc thread safe. > > There is another possibility: add a "*-*-ecos" target in GCC that would > use the ecos kernel functions to implement the gthread API. A complete > GCC port for eCos should also probably include a single/multi threaded > option (like the -pthread option for AIX targets) so that you can use a > bare eCos without kernel. Multilibbing on the basis of thread support might work (although the thought of doubling the number of multilibs on some toolchains fills me with dread), although I can tell you that the eCosCentric implementation doesn't need to do that - instead it's possible to abstract the GCC gthread implementation so that implementations can "plug in" to it if there is threading support. In the fullness of time (don't ask me when because I don't know other than "not soon") and this gets contributed to the gcc project, this is something I know they've been looking for in the past as it solves a number of wider issues, including on AIX. Certainly using pthreads isn't a great option because of the overheads to applications (and their semantics) it brings in. eCos native threads are definitely the way to go. More specifically, directly using the internal C++ API, rather than the kernel C API. The locking primitives are used so much by STL that you really don't want to have unnecessary overhead in there. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss