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,FREEMAIL_FROM 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!postnews.google.com!y80g2000hsf.googlegroups.com!not-for-mail From: Lucretia Newsgroups: comp.lang.ada Subject: Re: Implementing an Ada compiler and libraries. Date: 10 May 2007 11:06:28 -0700 Organization: http://groups.google.com Message-ID: <1178820387.916393.238070@y80g2000hsf.googlegroups.com> 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> NNTP-Posting-Host: 62.56.81.180 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1178820388 13926 127.0.0.1 (10 May 2007 18:06:28 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 10 May 2007 18:06:28 +0000 (UTC) In-Reply-To: <1178818792.829214.95870@q75g2000hsh.googlegroups.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Opera/9.10 (X11; Linux i686; U; en),gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: y80g2000hsf.googlegroups.com; posting-host=62.56.81.180; posting-account=G-J9fgwAAADgpzBiEyy5tO4f8MX5fbpw Xref: g2news1.google.com comp.lang.ada:15731 Date: 2007-05-10T11:06:28-07:00 List-Id: On May 10, 6:39 pm, Lucretia wrote: > On May 10, 8:59 am, "Dmitry A. Kazakov" > wrote: > > > > True, but is it possible to include dependency info within the object > > > itself? > > > Sure, it is just another "with". Each "with" loads (maps into the memory) > > the corresponding precompiled unit (compilation context). Some minor > > relocation stuff will be needed, checksums and time stamping as Gautier has > > mentioned. The symbolic tables (actually contexts) can be organized as a > > tree-stack to reduce loading overhead. "Use" plants a tree in the forest. I > > did such thing once. I guess it should make table look-ups slower. So the > > net effect on the compilation speed is unclear, before you actually build > > the thing. > > True, have been thinking about this today. Don't know about the speed, > it'd have to be tested with enough of a subset and enough compilation > units. ** This post may be a jumble of ideas ;D To elaborate some more, I've been thinking along the lines of: The parser matches a with statement, it then has to check to make sure this package has not already been with'd. If it hasn't, check to see if the package exists in binary form. If not, the compiler needs to start another compilation - this library unit just with'd then with the symbol table and go back to the original compilation. Now this would make either a recursive compiler, or a compiler with multiple tasks (if developed in Ada ;D). Also, allowing multiple compilation units in the same file can be problematic, e.g. package one is ...; package two is ...; procedure three is ...; package body one is ...; package body two is ...; What if the body of one or two require the subprogram three? Is this a form of forward declaration? Would interleaving specs and body's cause problems? Probably. I now think that I understand why GNAT chooses the model it has done, although I don't know whether the compiler handles dependency checking or if gnatmake does - it looks like gnatmake does, but underneath it could be the compiler. Another area I've thought about is the symbol table: 1) For a package spec, there is a public (is this the limited view?) and a private part, this can be compiled to symbol table. 2) For the package body, there is another private part which cannot be accessed outside of the spec unless exported in the public part of the spec, this can be compiled into the spec's symbol table or a separate one. 3) All other compilation units compile down to 1 symbol table. For a final build, only the public area of the package spec needs to be in the symbol table, in a debug build, the whole lot needs to be there. Thanks, Luke.