RE: Whatever happened to -fembedded-cxx?

RE: Whatever happened to -fembedded-cxx?

[Shiv Shankar Ramakrishnan]

Hi,

> (In case anybody is wondering why EC++ has reared its ugly head again,

I think EC++ is just a fancy name and a wrong way to address some of the
*percieved* problems in C++. As to why you should care about my opinion?
Well for one as a person who has recently understood why the Std C++
makes a lot of sense and why no other language comes close to offer all
that it does. Also I figured out that EC++ doesn't cut it at all inspite
of my having just about 1 year of real world C++ experience. You can
think of my views as how a till recently an outsider thinks about it.

I sometimes really think EC++ was dreamt up by people who didn't and
couldn't implement the whole Std C++ language. For example just why in
the world have they left namespaces and new style casts out of it?!
They features have absolutely NO runtime time/space costs. So aren't
they contradicting themselves? Rather at least the new style casts
(though they look unpretty) would be very usefull in embedded progra-
mming since then you can easily scan all typecasts that might be causing
crashes. I wonder if they are really helping embedded programming.

Also templates *may* cause code bloat but no speed loss. In fact C++ is
the only language that has come close matching the speed of optimised
Fortran for high performance scientific computing. Have a look at
http://www.oonumerics.org/blitz/
Do peruse through some papers there to expand your knowledge of what C++
can really do. So why have templates been totally dropped from EC++?!
Okay speed may not always be critical in embedded systems but it is for
Real Time embedded systems.

Still not convinced then please read what Stroustrup himself says on
EC++ -
http://www.research.att.com/~bs/bs_faq.html#EC++

> Apple is specifying EC++ for its I/O driver kit for OS X.

If Apple really wants to use C++ for the I/O driver kit then they should
rather have coding guidelines for not using features like exceptions
or RTTI (which might decrease runtime speed), and NOT by giving credence
to another subset of C++ that is going to confuse people and send all
the wrong signals. It is highly undesirable to use EC++ when the 
Standard is out. And this is a single platform thing so why should Apple
be worried about noncompliant compilers esp. that it might use GCC?

I really wish all the compiler vendors would pull up their socks and
have Std comforming compilers. For example partial template 
specialization is important for reducing template code boat, but many
commercial compilers don't implement it. If GCC can do it why not all
of them? I sometimes get really pissed off that I can't use even a
decent subset of std C++ due to the horrible mess that happens with
if you want to be cross platform/compiler. Sure you can stick to a
subset of C++ for that, (for the time being till things get better) but
doing that formally by something like EC++ is to discredit and belittle
the whole standards C++ process.

Thanks,
Shiv

Disclaimer -
Please regard the above as my personal opinion only. Others may disagree.

Re: Whatever happened to -fembedded-cxx?

[Mike Stump]

> Date: Wed, 22 Mar 2000 14:20:28 -0800
> From: Stan Shebs <shebs@apple.com>

> At one point, it seems that Cygnus GCC or egcs or both had a flag
> -fembedded-cxx that complained about C++ constructs that are not
> part of the Embedded C++ subset.  However, it doesn't seem to be
> available in current sources.  What's the story?

> (In case anybody is wondering why EC++ has reared its ugly head
> again, Apple is specifying EC++ for its I/O driver kit for OS X.
> And no, I wasn't around to influence that decision, but I will be
> happy to take any relevant data/opinions and pass them along, hint
> hint.)

I have never seen much of a need for Embedded C++.  It was always more
of a politic thing that a few people in the world (a group of isolated
programmers from an small isolated country on a small chain of
islands) thought was necessary for some reason, and they had some
bucks to spend to get a few vendors to cater to them.  They tried to
drum up support for it.  Luckily (or not), they picked a reall good
name, and got some press.

Sorry to hear Apple bought into it.  Some of the concepts that had are
right, but we don't need a marketing name for it.  -fno-excetions is
fine, and works for peolpe that want to use it.  -fno-rtti, ditto.
g++ has always had those options, and will have them for a long time
to come.  So in essence, g++ has supported and not needed Embedded C++
since before the term was born.

Hint g++ mostly supports Embedded C++ already in it's current form,
with a few extra features thrown in.  For example, they didn't spec
templates, because when they started specing, templates were new and
the compilers they had didn't necessarily all support them well and to
the same extent.  The 1990s are over.  We can add templates as a
feature to Embedded C++ just because it makes sense to.  It is like
adding long long support.  It just makes sense.  Same with namespaces.
Some of the other portions are just optimizations that we could do, if
people found that the optimization was important enough to them (no
MI).  But just maybe, newer ABIs and newer codegen strategies will
render these minor optimizations not worth it.  I feel we don't need
to carve these in hard stone, rather let us (the compiler developers)
respond to real needs or real people by offering whatever people want
(-fsljl-exceptions v -fnew-abi v -fno-excetions -v
-fnosjlj-exceptions for example).

Anyway, this is just my view of the world, and other people will
definitely have other views.  A well rounded view will also take into
consideration other views, and decide for themselves.

For an I/O driver kit for an operating system, far more important, is
the ABI people can write to, file formats, data layout, runtime
environment and so on.  I mean, if a person can code it in Pascal, and
meet the ABI requirement, why not let them code in Pascal.  Or real
C++ for that matter.

Re: Whatever happened to -fembedded-cxx?

[Jeffrey A Law]

  In message < 200003222345.AAA01391@loewis.home.cs.tu-berlin.de >you write:
   > I don't recall it ever being in egcs, so it must have been in Cygnus
  > gcc.
That is correct.

  > Well, I guess I can't say much more than has been said before, by
  > other people and on other forums. EC++ does not do what it claims to
  > do (in particular, the claim that it is a subset of standard C++),
  > compilers don't (necessarily) perform the optimizations they are
  > supposed to perform, and the selection of deleted features appears
  > arbitrary considering the target audiencs. In particular, I fail to
  > see why the removal of namespaces has any impact whatsoever on
  > performance of target code; pretty much the same holds for the removal
  > of templates.
This is the general reason why that code has never been contributed -- it's
never been clear that EC++ actually does what it is intended to do.

jeff

Re: Whatever happened to -fembedded-cxx?

[Martin v. Loewis]

> At one point, it seems that Cygnus GCC or egcs or both had a flag
> -fembedded-cxx that complained about C++ constructs that are not
> part of the Embedded C++ subset.  However, it doesn't seem to be
> available in current sources.  What's the story?

I don't recall it ever being in egcs, so it must have been in Cygnus
gcc.

> (In case anybody is wondering why EC++ has reared its ugly head
> again, Apple is specifying EC++ for its I/O driver kit for OS X.
> And no, I wasn't around to influence that decision, but I will be
> happy to take any relevant data/opinions and pass them along, hint
> hint.)

Well, I guess I can't say much more than has been said before, by
other people and on other forums. EC++ does not do what it claims to
do (in particular, the claim that it is a subset of standard C++),
compilers don't (necessarily) perform the optimizations they are
supposed to perform, and the selection of deleted features appears
arbitrary considering the target audiencs. In particular, I fail to
see why the removal of namespaces has any impact whatsoever on
performance of target code; pretty much the same holds for the removal
of templates.

Regards,
Martin

Whatever happened to -fembedded-cxx?

[Stan Shebs]

At one point, it seems that Cygnus GCC or egcs or both had a flag -fembedded-cxx
that complained about C++ constructs that are not part of the Embedded C++
subset.  However, it doesn't seem to be available in current sources.  What's
the story?

(In case anybody is wondering why EC++ has reared its ugly head again, Apple
is specifying EC++ for its I/O driver kit for OS X.  And no, I wasn't around to
influence that decision, but I will be happy to take any relevant data/opinions
and pass them along, hint hint.)

Stan