This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: "Documentation by paper"
- From: Peter Barada <peter at the-baradas dot com>
- To: law at redhat dot com
- Cc: kenner at vlsi1 dot ultra dot nyu dot edu, paolo dot bonzini at polimi dot it,gcc at gcc dot gnu dot org
- Date: Tue, 3 Feb 2004 11:48:01 -0500 (EST)
- Subject: Re: "Documentation by paper"
- References: <200402031634.i13GYTa3019190@speedy.slc.redhat.com>
> >Of course not, but it's always useful to define each term used at least
> >to some extent.
>Which I'm less and less inclined to do since we're using standard
>terminology dating back over 15 years (you can find dominators and
>dominator tree all the way back in the dragon book and probably
>earlier if you care to look).
>
>At some point you have to assume a base level of knowledge for your
>reader. Are we going to define CFG in every file which uses the CFG?
>Are we going to define the basic properties of SSA in every
>file which uses that form? Hmm, wait, you have to know what blocks
>and edges are to understand what a CFG is, so every file which uses the
>CFG has to also define blocks & edges. It's actually rather silly when you
>start to think about it -- particularly when we use a series of building
>blocks (blocks, edge, CFG, dominators, loop tree, SSA, value numbering) to
>implement an optimization or analysis pass.
Another possiblity is to have one file that has the definition of
terms, as well as bibliography entries for the papers and books that
the algorithms were derived from. That way if someone(like me who
took his last compiler course twenty years ago using the dragon book)
wanted to learn more about GCC and especially its optimizers, they could
use the bibliography as a guide to the relavent papers and books.
--
Peter Barada
peter@the-baradas.com