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: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Q: access to subprogram Date: 1996/07/11 Message-ID: #1/1 X-Deja-AN: 168313135 references: <4rb9dp$qe6@news1.delphi.com> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-11T00:00:00+00:00 List-Id: Ronald Cole said "Again not true. Yes, the source contains all the parts for each backend, but all the parts are not used to build the backend. Configure() will determine the correct source files and create links to properly build one target backend. The multiple backends at the source level are kept under the config subdirectory and grouped by architecture. I count thirty distinct backends:" Ronald is still missing the point that started this thread. There are two kinds of technologies. In one, the code generators for different target architectures are completely separate programs that may not even have the same overall design, let alone the same souce code. This approach is typical of a number of Ada 83 compiler technologies. The other kind of technology uses a single common source base for all backends. GCC is in this category. Yes, the configuration files differ, but the great majority of the code is common. This is a critical feature of GCC, and is what allows easy porting of the technology. To port to a new architecture, a new configuration file needs to be written, but not a new code generator. In the context of the original point in this thread, the critical thing is that if you have a change to the language which affects the backend, rather than just the front end, then the two technology approaches will be in a very different situation. In one case, you have to change multiple separate programs, in the other, unless the change affects configuration files, you only have to change one program. So far the Ada 95 changes have required zero changes to the configuration files, although eventually we anticipate some minor changes being required (and of course no change to configuration files is really minor, precisely because it has to be done in multiple cases). Ronald's technical comments on the GCC structure, while quite correct (after all I know this technology perfectly well, so we do not disagree on what is there) obscure the central point. There is a BIG difference between single-common-source-code-generator technologies and multiple-code-generator technologies when it comes to language changes that affect the back end. One of the design points in Ada 95 was to minimize changes that would impact backends, precisely because some Ada technologies (those using multiple separate front ends) could have been severely affected by such changes. On the other hand, if you use the GCC approach, the disctinction is not so important, and had we known that *all* Ada technologies used a single common source approach we might have made some design decisions differently, but in fact we knew this definitely was NOT the case.