Allow C++ or C99 in sim/*?

Allow C++ or C99 in sim/*?

[Andrew Cagney]

Hello,

Back in '95ish, I adopted ISO C 90 as its programming language for PSIM. 
  My decision was based on two assumptions: a C++ compiler would be more 
buggy than C; the C language would be easier for a compiler to optimize 
than C++; no one in their right mind still used K&R C.  Over time, the 
ISO C 90 assumption was gradually extended to other simulators (via 
sim/igen and sim/common) and that led to the sim/ directory requiring 
ISO C.  This was all well before gdb/ adopted ISO C 90.  History has 
shown this to be a good decision.

Now, many years later, I think its time to revisit this:

Should the simulator directories allow more modern languages?  I can see 
several options:

- C99 which would allow C++ comments:
	// a comment
and declarations anywhere:
	foo (); int i; bar ()
and access to int32 et.al. types.  What else?

- C++ which would also allow access to objects and (ulgh?) templates 
(replacement for the sim-endian macro stuff?)

- Oh what the heck, Java and gcj ...

C99 should be a done deal.  While I hate C++, making GDB developers 
debug C++ code would be a good thing (TM), and there are a few chunks of 
the simulator code that really shouldn't be C.  Java would be, well, 
interesting.

Thoughts?  Coding standards?

Andrew

Re: Allow C++ or C99 in sim/*?

[Daniel Jacobowitz]

On Fri, Aug 01, 2003 at 08:15:52PM -0400, Andrew Cagney wrote:
> Hello,
> 
> Back in '95ish, I adopted ISO C 90 as its programming language for PSIM. 
>  My decision was based on two assumptions: a C++ compiler would be more 
> buggy than C; the C language would be easier for a compiler to optimize 
> than C++; no one in their right mind still used K&R C.  Over time, the 
> ISO C 90 assumption was gradually extended to other simulators (via 
> sim/igen and sim/common) and that led to the sim/ directory requiring 
> ISO C.  This was all well before gdb/ adopted ISO C 90.  History has 
> shown this to be a good decision.
> 
> Now, many years later, I think its time to revisit this:
> 
> Should the simulator directories allow more modern languages?  I can see 
> several options:
> 
> - C99 which would allow C++ comments:
> 	// a comment
> and declarations anywhere:
> 	foo (); int i; bar ()
> and access to int32 et.al. types.  What else?
> 
> - C++ which would also allow access to objects and (ulgh?) templates 
> (replacement for the sim-endian macro stuff?)
> 
> - Oh what the heck, Java and gcj ...
> 
> C99 should be a done deal.  While I hate C++, making GDB developers 

I don't think C99 is a done deal:
  - GCC C99 support is still not finished, though it's mostly there now
    of course.
  - GCC 2.95 is still in wide use, and doesn't allow declarations after
    statements.
  - C99 _libraries_, which are the interesting bit, are very rare.  I
    bet that most of our commercial host platforms aren't all there
    yet.

I also don't see what C99 adds that would be particularly useful to
sim, besides maybe the int32_t etc. types.

> debug C++ code would be a good thing (TM), and there are a few chunks of 

Amen.

> the simulator code that really shouldn't be C.  Java would be, well, 

Also amen.  If it weren't so unlikely to fly, I'd suggest allowing C++
in GDB :) It really would make some things easier.  But requiring a C++
compiler for sim/ at least gives a step in that direction.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Allow C++ or C99 in sim/*?

[David Carlton]

On Fri, 01 Aug 2003 20:15:52 -0400, Andrew Cagney <ac131313@redhat.com> said:

> While I hate C++, making GDB developers debug C++ code would be a
> good thing (TM), and there are a few chunks of the simulator code
> that really shouldn't be C.

I'd vote for allowing C++.  But I will make my motivations clear: I
don't use sim at all, so I don't really care about it per se: I just
think it would be a good thing if GDB developers had to deal with C++
code more, and, if I'm working on GDB in a couple of years, I'll be
pushing for allowing C++ in GDB.

> Coding standards?

I can help with this if we go the C++ route.

David Carlton
carlton@kealia.com

Re: Allow C++ or C99 in sim/*?

[cgd]

At Sat, 2 Aug 2003 00:16:31 +0000 (UTC), "Andrew Cagney" wrote:
> Should the simulator directories allow more modern languages?  I can
> see several options:
> 
> - C99 which would allow C++ comments:
> 	// a comment
> and declarations anywhere:
> 	foo (); int i; bar ()
> and access to int32 et.al. types.  What else?

C99 isn't necessarily completely implemented, as has been pointed out.

While i occasionally like to use // comments, and find them more
visually appealing than /* */ comments, i don't think there's a strong
win in using them.

declarations "anywhere," IMO, just clutter things.  Personally, i'd
limit declarations to start of blocks and to perhaps one or two other
places, e.g. declaring local vars for use in 'for' loops.  ("for int i
= ...")

However, these things have been in c++ for a while, right?


> - C++ which would also allow access to objects and (ulgh?) templates
> (replacement for the sim-endian macro stuff?)

If the sim tree goes there to any large extent, then it would force
some simulator maintainers to learn C++.  I don't see that happening
any time soon, at least for one particular maintainer...  8-)


I guess it wouldn't hurt (much) to:

* make infrastructure compatible (to the extent easily possible),

* tolerate use of some (relatively minor) new language features in
  existing simulator code, and

* *possibly* encourage implementors of new sims to do so in different
  languages.


I must also say that performance *is* a concern.  Our goal in doing
sim work was to be able to real code (i.e., "telnet into the operating
system running on the simulator, communicating via the simulated
ethernet device which talks out on the real network...").  If
improving the system meant slowing it down much, then that would be a
real lose.

(honestly, i don't know enough about modern C++ to know if using it
extensively is likely to mean decrease in performance... but it's not
clear that there's great incentive for me to find out.  8-)



chris

Re: Allow C++ or C99 in sim/*?

[Andrew Cagney]

> C99 isn't necessarily completely implemented, as has been pointed out.
> 
> While i occasionally like to use // comments, and find them more
> visually appealing than /* */ comments, i don't think there's a strong
> win in using them.
> 
> declarations "anywhere," IMO, just clutter things.  Personally, i'd
> limit declarations to start of blocks and to perhaps one or two other
> places, e.g. declaring local vars for use in 'for' loops.  ("for int i
> = ...")
> 
> However, these things have been in c++ for a while, right?

I hope so.  Was using them in '90 :-)

>> - C++ which would also allow access to objects and (ulgh?) templates
>> (replacement for the sim-endian macro stuff?)
> 
> 
> If the sim tree goes there to any large extent, then it would force
> some simulator maintainers to learn C++.  I don't see that happening
> any time soon, at least for one particular maintainer...  8-)
> 
> 
> I guess it wouldn't hurt (much) to:
> 
> * make infrastructure compatible (to the extent easily possible),
> 
> * tolerate use of some (relatively minor) new language features in
>   existing simulator code, and
> 
> * *possibly* encourage implementors of new sims to do so in different
>   languages.
> 
> 
> I must also say that performance *is* a concern.  Our goal in doing
> sim work was to be able to real code (i.e., "telnet into the operating
> system running on the simulator, communicating via the simulated
> ethernet device which talks out on the real network...").  If
> improving the system meant slowing it down much, then that would be a
> real lose.
> 
> (honestly, i don't know enough about modern C++ to know if using it
> extensively is likely to mean decrease in performance... but it's not
> clear that there's great incentive for me to find out.  8-)

Two parts, and two features, come to mind:

- the sim-endian code which, I think, would work better using templates

- the h/w devices which are objects with virtual methods

I suspect a careful choice of language features will avoid the 
performance problems - no multiple inheritance for instance.

after that, well who knows.

Andrew

Re: Allow C++ or C99 in sim/*?

[Daniel Jacobowitz]

On Tue, Aug 05, 2003 at 12:25:26AM -0400, Andrew Cagney wrote:
> Two parts, and two features, come to mind:
> 
> - the sim-endian code which, I think, would work better using templates
> 
> - the h/w devices which are objects with virtual methods
> 
> I suspect a careful choice of language features will avoid the 
> performance problems - no multiple inheritance for instance.
> 
> after that, well who knows.

At which point, it seems, you're redesigning sid rather than sim?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Allow C++ or C99 in sim/*?

[Michael Elizabeth Chastain]

Not like I work in sim/ anyways ... so all this is from the
peanut gallery.

I like C++ more than C99.

If we go with C99, and actually start using C99 features, we'll get
unhappy users who still have C90 compilers.  And if we tell them "just
use gcc" (which I think is a valid response) then we might as well
go all the way to C++.

My experience with C++ is that it makes some maintenance tasks easier.
If there is a crappy class, it's easier to rip out / rewrite a class in
C++ than it is to do the equivalent in C.

We would get massive dogfood benefits from writing in C++.  That would
be the major benefit.

For a C++ coding standard, there are several views.  The official Bjarne
Stroustrup view is to use the whole freakin' language because every
feature in the language is there for a good reason.  For the purpose
of eating dogfood, that is a reasonable thing.

My personal view is that I stay away from templates and rtti because
they require link time support, thus are less portable.  Also I stay
away from namespaces because they confuse gdb.  That would be a reason
*for* using namespaces for us!  And I eschew exceptions because I don't
like the way they were glommed onto the language as an afterthought.

gcc 2.95.3 has a usable C++ compiler, although it's incomplete in many
areas.

Michael C