Allow C++ or C99 in sim/*?

Andrew Cagney ac131313@redhat.com
Tue Aug 5 04:25:00 GMT 2003


> 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




More information about the Gdb mailing list