public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jifl@jifvik.org>
To: Jerome Souquieres <jerome.souquieres@kis.fr>
Cc: eCos Discussion <ecos-discuss@ecos.sourceware.org>
Subject: Re: [ECOS] Re: C++ Support
Date: Sat, 21 May 2005 08:30:00 -0000	[thread overview]
Message-ID: <428DBF8C.1050409@jifvik.org> (raw)
In-Reply-To: <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

      reply	other threads:[~2005-05-20 10:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-19 15:08 [ECOS] " Raghavendra K
2005-05-19 15:58 ` [ECOS] setting up SLIP/PPP incoming connections Gonçalo Antunes
2005-05-20  2:14   ` Nick Garnett
2005-05-20  8:17     ` Gonçalo Antunes
2005-05-20 10:01       ` Nick Garnett
2005-05-19 19:40 ` Gonçalo Antunes
2005-05-20  9:50 ` [ECOS] Re: C++ Support Øyvind Harboe
2005-05-20 14:58   ` Jerome Souquieres
2005-05-21  8:30     ` Jonathan Larmour [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=428DBF8C.1050409@jifvik.org \
    --to=jifl@jifvik.org \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=jerome.souquieres@kis.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).