Implementing an Ada compiler and libraries.
in [ADA]
|
From: Lucretia on 11 May 2007 13:43 On May 11, 6:39 pm, Lucretia <lucret...(a)lycos.co.uk> wrote: > > package one is ... end one; > package two is ... end two; > package body one is ... end one; > package body two is ... end two; > > I take it, this is allowed? Also, further to the above, how do other compilers handle this? Janus? SofCheck? Does Tucker Taft still come here? Thanks, Luke.
From: Robert A Duff on 11 May 2007 14:20 Lucretia <lucretia9(a)lycos.co.uk> writes: > On May 11, 6:39 pm, Lucretia <lucret...(a)lycos.co.uk> wrote: >> > package one is ... end one; >> package two is ... end two; >> package body one is ... end one; >> package body two is ... end two; >> >> I take it, this is allowed? > > Also, further to the above, how do other compilers handle this? Janus? > SofCheck? Aonix uses the SofCheck front end. Anyway, an implementation is allowed to impose some requirements on the order of units within a file, but is not required to do so. It's the with_clauses that determine visibility of library units -- not their order in the source file. - Bob
From: Lucretia on 11 May 2007 14:49 On May 11, 7:20 pm, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > > Also, further to the above, how do other compilers handle this? Janus? > > SofCheck? > > Aonix uses the SofCheck front end. Ah yes. > Anyway, an implementation is allowed to impose some requirements on the > order of units within a file, but is not required to do so. It's the Yep. > with_clauses that determine visibility of library units -- not their > order in the source file. True, but how would a compiler that didn't impose limits (are there any?) manage to find compilation units with'd? 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, 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? Thanks, Luke.
From: Georg Bauhaus on 11 May 2007 16:34 On Fri, 2007-05-11 at 11:49 -0700, Lucretia wrote: > how would a compiler that didn't impose limits (are there > any?) manage to find compilation units with'd? At least with GNAT it > uses package name => filename, GNAT also comes with gnatchop, pragma Source_File_Name, and naming conventions. > i.e. how do you know in which file to look? Have you had an opportunity to look at the contents of the library and info files generated by the Aonix (SofCheck) compiler?
From: Robert A Duff on 11 May 2007 18:06
Lucretia <lucretia9(a)lycos.co.uk> 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 |