Re: Possible Ada deficiency?

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccbrbx3qbp.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
> >... inline is a hint and the
> > dependencies need not (and should not) be used. Do any inlining/macro
> > expansion at link-time.
>
> I don't see link-time as an improvement.  Whether you do this work at
> compile time or link time, it still costs in terms of rebuild time.
> And either way, you have to redo the work when the body changes.

Sure, but if the extra rebuild time isn't significant, who cares?

> >...Certainly I wasn't the only one who thought that was
> > the intent.
>
> But you're the only one who implemented it that way!

I certainly wasn't the only one to share generics by default. I'm pretty
sure the old Rational compiler worked the same way. I'm the only one
bull-headed enough to maintain that approach in the face of Ada 95, though.
:-)

> >...Machines of the era weren't really powerful enough to implement
> > that intent, thus the hacks of the generic dependency and the inline
> > dependency were allowed.
> >
> > Of course, Ada 95 came along and changed that intent.
>
> I don't understand that.  Maybe I don't understand what you mean by
> "that intent".  Which rules of Ada 95 are you talking about, here?

There are many rules of Ada 95 that make sharing impractical (not
impossible, just impractical). For instance, there was no reason in Ada 83
to make the size of generic formal types the same as the actual type. (Ada
95 requires that because of aliased objects.) Whereas, Ada 83 had just one
(the previously mentioned parameter passing style), and there never has been
a test written that could show the difference (such a test would be very
dubious anyway).

> >... Which is too bad, as
> > machines now are powerful enough to implement the Ada 83 intent!
>
> I don't understand that, either.  Are you saying that the run-time
> overhead of the always-share model is now acceptable?

No, I was thinking of the time/space requirements for building such a
compiler "properly". We didn't really implement my design because our hosts
didn't have enough memory to store the intermediate code for the entire
program, and a disk-based solution would be way too slow. It would be
practical on modern machines (other than that I can't predict the
performance of the optimization pass, which would be critical to making the
scheme work. We'd have to build it to see).

Note that with the design that I had in mind, the run-time overhead of
"always share" (as you put it) would be greatly reduced by partial
evaluation and inlining optimizations -- done at link-time so that all of
the instantiations and calls are known. Plus, pragma Inline could be used to
reduce the overhead to nearly nil on critical stuff. The problem isn't the
run-time overhead so much as it is supporting the optimizations necessary to
mitigate it.

                                Randy.



> - Bob