home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!sdd.hp.com!hp-cv!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
- From: bbx!bbx.basis.com!scott@unmvax.cs.unm.edu (Scott Amspoker)
- Newsgroups: comp.compilers
- Subject: Re: Pros and cons of high-level intermediate languages
- Keywords: translator, design
- Message-ID: <92-07-070@comp.compilers>
- Date: 22 Jul 92 15:54:48 GMT
- Article-I.D.: comp.92-07-070
- References: <92-07-064@comp.compilers> <92-07-068@comp.compilers>
- Sender: compilers-sender@iecc.cambridge.ma.us
- Reply-To: bbx!bbx.basis.com!scott@unmvax.cs.unm.edu (Scott Amspoker)
- Organization: BASIS International, Ltd., Albuquerque NM USA
- Lines: 59
- Approved: compilers@iecc.cambridge.ma.us
-
- ssp@csl36h.csl.ncsu.edu (Santosh Pande) writes:
- > I am interested in knowing the pros and cons of using an
- >intermediate language (IL) in general. In particular I find 'C' has been
- >used extensively as the IL in many situations: Modula, SISAL, AT&T Cfront
- >for C++ etc.
-
- We've been using C as an IL for an object-oriented data processing
- language which includes Mesa-style exception handling (quite elegant but
- tricky to implement). Here are a few odds and ends we have discovered
- about using C as an IL:
-
- * Generating C code can sometimes be more tedious than generating
- assembler. Identifiers generally must be preserved and properly
- used and scoped in the C code. Structures have field names - not
- merely a list of offsets. Also, you must either second guess the
- host C implementation (i.e. alignment and sizeof() stuff) or
- generate 100% symbolic code - either approach has its problems.
- Local identifiers (especially typedefs) sometimes have to be moved
- outside a procedure so they can be accessed by additional
- compiler-generated procedures (or re-created locally within those
- procedures).
-
- * Never approach such a project thinking that all you're doing is
- creating a "front end". Treat it as you would any native code
- compiler.
-
- * I quickly developed a deep appreciation for the C comma operator.
-
- * The ANSI spec which renders stack variables unpredictable after
- a longjump() sucks. This is solved by declaring them 'volatile'
- but then you might lose bigtime in the optimizer.
-
- * The lack of a global 'goto' makes certain things a little less
- efficient. This is especially true for generating glue routines
- to fix the "this" pointer enroute to a virtual method.
-
- * Some C compilers can certainly improve the way they pass small
- structures to and from functions.
-
-
- All in all I think using C as an IL is a smart way to go for many, if not
- most, applications. We have better things to do than to re-invent a
- native code generator and its associated optimizer for each new platform.
- It's true that there can be some performance penalties. Some of these
- penalties can be blamed on C itself. However, most of them come from
- using some of the high-level features provided by the "front end language"
- which generates the C code. Such performance degradation can be minimized
- by using a little common sense and is (IMHO) more than offset by the
- productivity gains reaped from using high-level features. As usual, the
- secret to success is to know where most of the work is being done and
- concentrate on those areas.
-
- --
- Scott Amspoker
- Basis International, Albuquerque, NM
- scott@bbx.basis.com
- --
- Send compilers articles to compilers@iecc.cambridge.ma.us or
- {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
-