From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99ab4bb580fc34cd X-Google-Attributes: gid103376,public From: kenner@lab.ultra.nyu.edu (Richard Kenner) Subject: Re: Q: access to subprogram Date: 1996/07/07 Message-ID: <4rpgkb$kc8@news.nyu.edu>#1/1 X-Deja-AN: 167552874 references: organization: New York University Ultracomputer Research Lab newsgroups: comp.lang.ada Date: 1996-07-07T00:00:00+00:00 List-Id: In article 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.