Re: why did you chose compiler development?

salomon@silver.cs.umanitoba.ca (Daniel J. Salomon)
25 May 1997 13:33:14 -0400

          From comp.compilers

Related articles
why did you chose compiler development? ast@halcyon.com (1997-05-22)
Re: why did you chose compiler development? salomon@silver.cs.umanitoba.ca (1997-05-25)
Re: why did you chose compiler development? walter@bytecraft.com (Walter Banks) (1997-05-25)
Re: why did you chose compiler development? scotts@metaware.com (Scott Stanchfield) (1997-05-25)
Re: why did you chose compiler development? thetick@scruz.net (Scott Stanchfield) (1997-05-27)
Re: why did you chose compiler development? marssaxman@sprynet.com (1997-05-27)
Re: why did you chose compiler development? ian@five-d.com (1997-05-30)
Re: why did you chose compiler development? conway@mundook.cs.mu.OZ.AU (1997-05-30)
[1 later articles]
| List of all articles for this month |

From: salomon@silver.cs.umanitoba.ca (Daniel J. Salomon)
Newsgroups: comp.compilers
Date: 25 May 1997 13:33:14 -0400
Organization: Computer Science, University of Manitoba, Winnipeg, Canada
References: 97-05-242
Keywords: practice

Andrew Tucker <ast@halcyon.com> wrote:
|> 3) It is the very picture of module coupling and cohesion. Breaking
|> down the process into front/middle/back ends and making each one
|> independent of each other is a textbook case that predates the ideas
|> from structured design.


Actually most compilers are a disaster in terms of module coupling.
The traditional splitting of syntax analysis into a scanner and a
parser is a good example of the problem. The scanner and parser must
not only share token codes, but the implicit information about which
tokens are represented totally by their token codes, and which tokens
are only useful when accompanied by token values (such as identifiers
& literal constants.) The type information about token values must
also be shared. In the case of lex and yacc the shared information
that is not described by the function interface involves a whole
header file of information namely "y.tab.h". If you pass all token
values as strings, the interface is somewhat simpler, but then you are
forced to rescan the numeric strings later to get their actual binary
values. In any case, the token value is usually transmitted as global
variables for efficiency, which is a coupling flaw.


Another example of excessive module coupling is in the sharing of the
symbol table between the front end and the back end. The symbol
attributes are usually shared as global information accessed through
symbol-table management routines. In good coupling between modules,
all information is passed as parameters.


For an example of poor cohesion of the modules of a compiler consider
again the scanner module. The scanner module can be described as
having only "logical cohesion." Logical cohesion is exhibited by a
module consisting of tasks that are similar in nature, but are
otherwise unrelated. The tasks in this are the recognition of each of
the different types of tokens. The unrelatedness of the tasks is
demonstrated by the fact that in a typical scanner, the specification
and recognition of identifiers, numeric values, literal character
strings, and comments, have little or no common code. Logical
cohesion is considered to be undesirable cohesion that one tries to
eliminate by splitting a module exhibiting only this kind of cohesion
into many separately invoked modules. (For more information on
logical cohesion, see M. Page-Jones, The Practical Guide to Structured
Systems Design, Second Edition, pp 58-102, Yourdon Press.) Real
scanners are rarely split in this way, because one would then get too
many modules to manage effectively, and a very inefficient scanner
that performs excessive module invocation.




To return to your original question, I myself entered the area of
compiler construction as a vehicle to achieve my goals in
programming-language design. This reason was missing from your list.
--
Daniel J. Salomon -- salomon@cs.UManitoba.CA
              Dept. of Computer Science / University of Manitoba
              Winnipeg, Manitoba, Canada R3T 2N2 / (204) 474-8687
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.