Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!mcvax!ukc!eagle!dcl-cs!bath63!pes
From: pes@bath63.UUCP
Newsgroups: comp.sys.atari.st
Subject: Re: Porting GCC to Atari ST
Message-ID: <891@bath63.ux63.bath.ac.uk>
Date: Thu, 2-Apr-87 04:12:15 EST
Article-I.D.: bath63.891
Posted: Thu Apr  2 04:12:15 1987
Date-Received: Sat, 11-Apr-87 05:52:05 EST
References: <3450@elroy.Jpl.Nasa.Gov> <975@ames.UUCP> <2822@mit-hermes.AI.MIT.EDU> <1090@ames.UUCP> <15901@sun.uucp> <597@elmgate.UUCP>
Reply-To: pes@ux63.bath.ac.uk (Paul Smee)
Organization: AUCC c/o University of Bath
Lines: 25
Keywords: C GCC Gnu FSF


Gosh, language wars.  I think the language is evolving.  When I was studying in
Cambridge (Massachusetts), and then still when I was writing compilers for
mainframes, the terms I was taught (and then used) defined:

  assembler -- program to go from assembly language mnemonics to binary object
         code (probably requiring linking).

  compiler --  program to go from a higher-level language to binary object
         code (probably requiring linking).

  trnaslator -- program to go from any language to any other language,
         including from a higher-level one to assembly language output.

However I note that the present books (Gries, and Aho and Ullman) define
compiler to mean 'from a higher-level language to either binary object or
assembly language' -- and, they define the code generator to be that part
of the compiler which produces the binary object or assembly language output
from the internal representation of the source produced by the parser (and
as muddled by any optimisation passes).

I'm a bit annoyed (must be old age) by this subtle shift in meaning, because
I think it eliminates a useful distinction.  Still, looks like, in today's
terms, both of the previous arguers are using the terms correctly -- just,
unfortunately, differently.  Sigh.