From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,91d0d8cd28bbb477 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!out03a.usenetserver.com!news.usenetserver.com!in04.usenetserver.com!news.usenetserver.com!nx02.iad01.newshosting.com!newshosting.com!198.186.194.247.MISMATCH!news-out.readnews.com!news-xxxfer.readnews.com!newspeer1.nwr.nac.net!newspeer.monmouth.com!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Implementing an Ada compiler and libraries. Date: Fri, 11 May 2007 18:06:18 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1178721451.073700.10730@y80g2000hsf.googlegroups.com> <6819scxft9y4$.1vlh83ppnnyrh$.dlg@40tude.net> <1178731280.075981.23040@u30g2000hsc.googlegroups.com> <8cu67r7wcdn7$.18rtn6g7506w2$.dlg@40tude.net> <1178818792.829214.95870@q75g2000hsh.googlegroups.com> <1178820387.916393.238070@y80g2000hsf.googlegroups.com> <4644179d$1_5@news.bluewin.ch> <1178905186.012787.167150@y80g2000hsf.googlegroups.com> <1178905389.489947.61760@o5g2000hsb.googlegroups.com> <1178909398.745971.215770@o5g2000hsb.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1178921178 4243 192.74.137.71 (11 May 2007 22:06:18 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 11 May 2007 22:06:18 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:XFHx7g1TkCdHRK/fa7E2n+E16Vs= Xref: g2news1.google.com comp.lang.ada:15773 Date: 2007-05-11T18:06:18-04:00 List-Id: Lucretia writes: > True, but how would a compiler that didn't impose limits (are there > any?) manage to find compilation units with'd? Here's one way: I presume the way one invokes the compiler is via a "build" tool of some sort (something like gnatmake or adabuild). Keep a data structure that tells which compilation units are in which source files. Whenever the build tool is invoked, it first parses all the files that changed since last time, and updates this data structure. If any files are new, they need to be parsed. If any files have been deleted, all information about them in the data structure should be deleted. You can store this data structure on disk, if you like. At this point, give an error if there are duplicate names (unless the user has explicitly requested that one should override the other). Now you have all the information you need to run the rest of the compiler phases (after parsing) on everything in the right order (or partially in parallel). I know this method can be implemented efficiently, because I've done it several times (not for Ada compilers, but for other language processing tools (Ada and non-Ada)). >... At least with GNAT it > uses package name => filename, so that's easy to implement, but with > multiple compilation units per file, it's much more tricky. I've > basically thought the only way to partially do it is to compile the > source into a parse tree, then traverse it to generate the AST, Generate the AST from the parse tree? I normally generate the syntax tree directly during parsing. You can save the syntax trees on disk, if you like. Or in memory. The nice thing about saving syntax trees is that they depend only on one source file. When you modify one source file, you might need to do semantic analysis and code gen on many things, but you only need to parse one thing. If you store things on disk, you have to be very careful to prevent them from becoming corrupt. Otherwise, the user will end up having to start over from scratch all the time, defeating the purpose. >... symbol > tables, dependencies, etc. You then have the problem of finding a unit > within a file? i.e. how do you know in which file to look? - Bob