home | list info | list archive | date index | thread index

Re: [OCLUG-Tech] Re: Parsing when compiling C - generalized understanding question?

  • Subject: Re: [OCLUG-Tech] Re: Parsing when compiling C - generalized understanding question?
  • From: Martin Hicks <mort [ at ] bork [ dot ] org>
  • Date: Fri, 30 Sep 2005 08:40:42 -0400

On Thu, Sep 29, 2005 at 08:22:12PM -0400, William Case wrote:
> Thanks Brenda, Martin and Normand;
> On Thu, 2005-09-29 at 13:28 -0400, Brenda J. Butler wrote:
> > 
> > If you *really* want to know more about how compilers work you should:
> > Read the dragon book
> I have heard of the dragon book and I hope to peruse it in the near
> future.
> > Read o'reilly's Lex and Yacc
> More than I need to know I think.
> > Take an undergrad compilers course at university
> Me and universities will never mix.

What I'm trying to point out here is that this stuff is complex.  If you
think Lex and Yacc is too much detail then don't even bother getting the
dragon book.  Lex and yacc is easier to understand than Dragon.

> > Read the gcc sources and be prepared to welcome death
> I am ready to accept death soon.
> I have no intention of ever building a compiler, although the logic of
> using things like BNF or EBNF seems intriguing.  In my reading, for
> example, I saw the rule of reducing *\ comments to one empty space.  I
> was hoping that somewhere in the literature or easily accessible through
> source code I could find other rules.  Brenda has supplied me with a
> verbal answer about the use of braces and semi-colons and I don't
> distrust any advice that she would give me.  However, as I was reading
> about compiling I thought "Just maybe there is an easy way to see for
> myself what is happening internally when the compiler translates."  It
> wouldn't have been the first time that I had discovered that something
> that I thought was hard to follow in Linux turned out to in fact be
> easy.  Alas, apparently not this time.

There is not.  Compiling in modern compilers is a complex process that
goes through more than one step between source language and final

> I am going to take you at your word and ask the following questions
> about compiling.
> OK, here goes!
> In my info index I have at least the following files related to
> compiling: make, gcc, flex, yacc, bison, cpp, ld, as, NASM, gdb, DDD and
> I am sure many others I haven't recognized.

Short answer:  You probably don't need most of them.

gcc - compiler.  Also invokes the preprocessor and perhaps the linker,
depending on your compile options.

flex - a lexer  (see lex and yacc).  Look up the definition of a lexeme.

bison/yacc - both are parser generators.  (see lex and yacc)

cpp - c pre processor.  For preprocessing macros in source code (c/c++)

ld - linker.  Links stuff :-)

as - assembler.

nasm - I think this is an intel assembler.

gdb - gnu debugger.  for debugging.

DDD - a graphical debugger front-end for gdb.

re: make

yes, make uses "rules" to compile stuff, or more generally, to process
stuff.  Sometimes you don't actually compile source code. i.e.,
generating documentation or converting from .txt to .ps could use a

The easiest way to learn to use make is to look at a few simple
makefiles.  The ones that are generated using a "configure" script are
notoriously difficult to understand because they are automagically
generated using scripts.


Martin Hicks || mort [ at ] bork [ dot ] org || PGP/GnuPG: 0x4C7F2BEE