Implementing an Ada compiler and libraries.
in [ADA]
|
From: Lucretia on 11 May 2007 18:37 On May 11, 9:34 pm, Georg Bauhaus <bauh...(a)futureapps.de> wrote: > > 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? No, I don't have a Windows installation at the moment. Luke.
From: Lucretia on 11 May 2007 18:41 On May 11, 11:06 pm, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > Lucretia <lucret...(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. So, essentially you're saying create a project file which lists which compilation units are in which files then the build tool will know where they are? > 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. Well, I was thinking that as you didn't know which compilation units were in which files, then building a tree without checking, you can then parse the tree and when you hit a "with" node, you then start looking for other compilation units. Just a thought ;D Thanks, Luke.
From: Ludovic Brenta on 13 May 2007 08:03 Duncan Sands writes: > On Thursday 10 May 2007 23:00:59 Pascal Obry wrote: >> Duncan Sands a écrit : >> >> Why not play on a C generator for the Ada language ? >> > >> > I have one! I'm porting the GNAT Ada f-e to LLVM >> > (http://llvm.org/), which replaces the gcc code >> > optimizers with those of LLVM. LLVM has a C backend >> > which turns its IR into C. >> >> Interesting, I'll probably have a look at some point. Thanks. > > It will most likely be available with LLVM 2.1. I will post > an announcement here when I release it. In the mean time, do you have a public repository? Do you welcome contributions? -- Ludovic Brenta.
From: Randy Brukardt on 16 May 2007 15:40 "Lucretia" <lucretia9(a)lycos.co.uk> wrote in message news:1178905389.489947.61760(a)o5g2000hsb.googlegroups.com... > 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? Janus/Ada works roughly the same as Aonix; the compilations are run as if they are separate compilations given to the compiler in the order that they exist in the source file. Personally, I don't think anything else makes sense, but as someone noted, there isn't any rule specifying how this must work. Randy.
From: Randy Brukardt on 16 May 2007 15:58
"Robert A Duff" <bobduff(a)shell01.TheWorld.com> wrote in message news:wccfy65n2pq.fsf(a)shell01.TheWorld.com... .... > If you do this, you need to design a permanent (on disk) representation > that is small. I think it's possible, but it's not easy -- the > "obvious" representation of symbol tables will be 10 times larger than > the source code. If it's 10 times larger, then it defeats the purpose > -- reading it in from disk will be slower than re-analyzing the original > source code. I don't quite buy this. "10 times larger" seems to be a gross overestimate (for Janus/Ada, it tends to be more like 2-3 times, and we did little to make the disk files smaller -- they're not the limited factor for compilation speed). It's necessary to keep the symbol table memory use reasonable (else paging costs will eat you up), and directly translating that to disk files is straightforward. Also, the cost of reading files vs. reparsing depends very much on how much effort is encoded in the files. Reading text is slower than known size binary files to begin with (although on modern machines, the difference isn't that significant), and there is a lot of other work that needs to go on to analyze a source file. My experience is that Janus/Ada is faster than Gnat on most compilations (although the difference isn't really significant, except on very large files where Gnat is faster because the Janus/Ada optimizer is worse than quadratic in program size). Randy. |