Re: How to justify teaching compilers

Randy <rand@rice.edu>
9 Oct 2004 22:35:28 -0400

          From comp.compilers

Related articles
[5 earlier articles]
Re: How to justify teaching compilers tk@ic.unicamp.br (Tomasz Kowaltowski) (2004-10-04)
Re: How to justify teaching compilers genew@mail.ocis.net (Gene Wirchenko) (2004-10-04)
Re: How to justify teaching compilers slimick@venango.upb.pitt.edu (John Slimick) (2004-10-04)
Re: How to justify teaching compilers nmm1@cus.cam.ac.uk (2004-10-09)
Re: How to justify teaching compilers torbenm@diku.dk (2004-10-09)
Re: How to justify teaching compilers monnier@iro.umontreal.ca (Stefan Monnier) (2004-10-09)
Re: How to justify teaching compilers rand@rice.edu (Randy) (2004-10-09)
Re: How to justify teaching compilers vbdis@aol.com (2004-10-09)
Re: How to justify teaching compilers house@usq.edu.au (Ron House) (2004-10-09)
Re: How to justify teaching compilers rbates@southwind.net (Rodney M. Bates) (2004-10-12)
| List of all articles for this month |

From: Randy <rand@rice.edu>
Newsgroups: comp.compilers
Date: 9 Oct 2004 22:35:28 -0400
Organization: Rice University, Houston, TX
References: 04-10-009
Keywords: courses
Posted-Date: 09 Oct 2004 22:35:27 EDT

Pg Nor Jaidi Pg Tuah wrote:
......
> If you can compromise and reduce compiler to just a few hours of
> lectures (embedded in, say, "systems programming"), what would you
> cover?


That depends on what you're trying to accomplish in those few hours:


1) If you want to summarize compilers with a quick survey of the main
points


2) If you want to introduce compiler-related topics as skills in their
own right


If you're going to attempt #2, it seems to me that these topics would
be useful:


- principles and trade offs in interpreting and compiling (compile
time vs run time issues, speed vs. portability, size of source
vs. size of executable, security, dynamic typing, type safety, syntax
and semantics, correctness and its limits (halting problem), etc)


- principles of scanning and LL(k) parsing


- description of how a program and its data are mapped into memory as
a process (stack, data, heap), especially how there are reported by
O/S utilities (.bss, .data, .text, etc) and used by the assembler.


- description of how a function's arguments are passed (in, out, in/out)


- description of the fluid boundary between where the compiler ends and O/S
services (and libraries) begin


- description of tools that reveal info about the internals of executables (and
libraries) and how they are useful (e.g. Linux's binutils):
    - ldd (what is dynamic linking; how does it work)
    - nm, strings (what are 'symbols'; what is 'mangling')
    - size
    - ld, ld.so
    - ar, ranlib


- typical runtime problems that arise from mis-compilation or mis-linking:
    - problems with mismatched function arguments (number, size, type)
    - problems with dynamically-linked libraries
    - problems with data alignment
    - problems with exceeding stack size or address space
    - explanation of some of the basic errors: seg fault, invalid address, etc
    - typical symptoms of stack corruption
- how to identify or debug these and other errors


        Randy


--
Randy Crawford http://www.ruf.rice.edu/~rand rand AT rice DOT edu


Post a followup to this message

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