public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: cgd@broadcom.com
To: ac131313@redhat.com
Cc: gdb@sources.redhat.com
Subject: Re: Allow C++ or C99 in sim/*?
Date: Sat, 02 Aug 2003 01:30:00 -0000	[thread overview]
Message-ID: <yov5vftgzw03.fsf@ldt-sj3-010.sj.broadcom.com> (raw)
In-Reply-To: <mailpost.1059783391.21631@news-sj1-1>

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

  parent reply	other threads:[~2003-08-02  1:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-02  0:16 Andrew Cagney
2003-08-02  0:43 ` Daniel Jacobowitz
2003-08-02  0:47 ` David Carlton
     [not found] ` <mailpost.1059783391.21631@news-sj1-1>
2003-08-02  1:30   ` cgd [this message]
2003-08-05  4:25     ` Andrew Cagney
2003-08-05  4:27       ` Daniel Jacobowitz
2003-08-02  1:11 Michael Elizabeth Chastain

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=yov5vftgzw03.fsf@ldt-sj3-010.sj.broadcom.com \
    --to=cgd@broadcom.com \
    --cc=ac131313@redhat.com \
    --cc=gdb@sources.redhat.com \
    /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).