Re: Q: access to subprogram

[kenner@lab.ultra.nyu.edu (Richard Kenner)]

In article <dewar.836776773@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
>If you have a technology where each backend is a completely different source
>program, separately written (such technoologies are pretty common, most Ada 83
>compiler technologies were like this), then the point is that the impact
>of anything that affects the backend is greatly multiplied, and that is
>why during the design, we were very cautious about changes that affect
>the backend.
>
>But for technologies like GCC, where there is only one source program for
>both front end and backend (though in both cases multiple executables),
>this distinction is not significant.

I'd say it's not *as* significant.  However, in GCC we are concerned
about things that affect the config files.  We try to avoid making
changes that affect existing config files if at all possible and then
we much prefer changes (such as adding a new parameter to a macro)
that can be made "mechanically" to all the config files.

But adding new requirements on the config files is something we try to
avoid, though the work on folding a "zero-cost" exception handling
into GCC is going to require at least some additional work in
each config file.