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,c83ae8c4e40baa79 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Ada front end technology Date: 1997/07/07 Message-ID: #1/1 X-Deja-AN: 255329335 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1997-07-07T00:00:00+00:00 List-Id: Robert Dewar (dewar@merv.cs.nyu.edu) wrote: : Jon is really confused on his history here. Intermetric's approach of : generating a front end that can be sold and used for rehostings is : hardly new. DDCI, Alsys, and Verdix were all in this business, as well : as other vendors with considerable success. For example, Alsys sold its : front end to Unisys and to HP. Many other such deals were concluded. : It is nice to see Intermetrics continue this tradition, but it is not : a new invention that someone "finally somewhere produced". Many of the : Ada 83 technologies were designed to be portable in this sense, and : the fact that they succeeded is seen in the many Ada 83 products that : used third party front ends. Although I basically agree with Robert, one thing that makes AdaMagic a little different is that rather than defining our own intermediate language (IL), and then using some kind of "gasket" to connect it to an existing back end, we took a more IL-neutral approach in our front end. This has allowed us (or a licensee) to adapt the compiler relatively easily to directly generate the IL of an existing back end. This was what allowed us to adapt the front end to generate Java bytes codes as well. A legitimate response to this is that there is no real difference between "adapting the front end" and "building a gasket," but having worked on various compilers, I can say there is a qualitative difference in the effort involved in adapting the front end, and it feels very different from the effort involved in building a "gasket." I also think the results are somewhat better for the "adaptation" approach than the "gasket" approach. >From what I know of the GNAT front end, it could also be "adapted" to generate other ILs, but there is no real need to do so given the adaptability of the existing GCC back end. On the other hand, of what I know of most Ada 83 front ends, they could not be easily adapted to generate (significantly) different ILs. Part of this is traceable directly to the source-based approach of AdaMagic and GNAT. Since they don't need to create a persistent representation of the symbol table, they are not "involved" with any particular kind of persistent IL, and can use a more adaptable "procedure-call" interface for generating IL. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA