This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Re: C++ Support
- From: Jonathan Larmour <jifl at jifvik dot org>
- To: Jerome Souquieres <jerome dot souquieres at kis dot fr>
- Cc: eCos Discussion <ecos-discuss at ecos dot sourceware dot org>
- Date: Fri, 20 May 2005 11:44:28 +0100
- Subject: Re: [ECOS] Re: C++ Support
- References: <s28ce078.016@EMAIL> <1116574872.10422.23.camel@localhost.locald omain> <428DB2AB.10106@kis.fr>
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