From: Jim Blandy <jimb@redhat.com>
To: Hilfinger@otisco.mckusick.com
Cc: ac131313@redhat.com, aidan@velvet.net, drow@mvista.com,
per@bothner.com, green@redhat.com, muller@cerbere.u-.strasbg.fr,
gdb-patches@sources.redhat.com
Subject: Re: [RFA] Add type support for Ada
Date: Wed, 02 Oct 2002 11:57:00 -0000 [thread overview]
Message-ID: <vt2lm5gadk8.fsf@zenia.red-bean.com> (raw)
In-Reply-To: <200209280925.CAA10025@otisco.McKusick.COM>
"Paul N. Hilfinger" <hilfingr@otisco.mckusick.com> writes:
> > It looks to me as if the string cleanup stuff is distinct from the
> > fixed instance stuff. These should be submitted as separate patches.
>
> They definitely are logically separate changes.
>
> > Is a `fixed instance' a feature of the language's type system itself?
> > That is, is it something that an Ada programmer actually knows about?
> > Or is it something used internally within GDB, or internally by some
> > implementations of Ada?
>
> It is not a language feature, but rather an optimization. The original
> problem was that STABS and also GDB's internal type representation
> was not adequate for representing "dynamic" Ada types---i.e., those that,
> unlike C types, have data-dependent sizes. The scheme we hit on (in
> retrospect perhaps not the best) was to encode a bunch of auxiliary
> information into our type names, and to introduce additional types
> carrying additional (encoded) information.
>
> When Ada evaluation routines discover that a quantity has an encoded
> type, they know to compute a conventional, fixed-sized GDB type based on the
> data, and to attach this type to the value they are producing.
>
> Unfortunately, the computations involved are expensive---involving type
> lookups in some cases---and we don't want to repeat them unnecessarily.
> Hence the flag.
Thanks for the explanation. Since this isn't a language feature, but
an implementation detail, the patch needs to add comments that explain
it in full detail. Something like the above, but with the exact Ada
terminology stuck in at the right places, would be a start.
prev parent reply other threads:[~2002-10-02 18:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-25 20:00 Aidan Skinner
2002-09-26 19:24 ` Andrew Cagney
2002-09-27 13:08 ` Jim Blandy
2002-09-28 2:24 ` Paul N. Hilfinger
2002-09-30 20:17 ` Aidan Skinner
2002-10-02 11:59 ` Jim Blandy
2002-10-02 11:57 ` Jim Blandy [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=vt2lm5gadk8.fsf@zenia.red-bean.com \
--to=jimb@redhat.com \
--cc=Hilfinger@otisco.mckusick.com \
--cc=ac131313@redhat.com \
--cc=aidan@velvet.net \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
--cc=green@redhat.com \
--cc=muller@cerbere.u-.strasbg.fr \
--cc=per@bothner.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