Implementing an Ada compiler and libraries.
in [ADA]
|
From: Lucretia on 10 May 2007 13:39 On May 10, 8:59 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> 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. > >> An interesting issue is cross-platform library units, I was playing with > >> this idea, but came to no conclusion. > > > LLVM would be capable of this. > > Then is not a cross-platform, I mean the only platform here is the VM. > Otherwise, it could be doable. Though many static things which are > platform-dependent will cease to be compile-time static. So you will be > unable to have certain things fully precompiled. Well, no, the target is the VM, but it can be translated into any back- end, thus portable to some degree. > > Why? Are you saying that it would be better to store libraries in IR > > rather than binary form? > > IR = infra red? ;D Intermediate Representation > >> Or a database, for that matter... > > > Like the old Ada library? > > It wasn't that bad. DEC Ada had a library, if I correctly remember. With an > integrated source control system it might become more attractive than the > GNAT model. If I designed Ada tool-chain (the compiler is only a part of), > I would probably choose this. That's actually not a bad idea. > > I was actually thinking, if I couldn't embed > > the other information required by the compiler into the final object, > > then a separate "lib" containing only this informaton would be > > necessary. > > You mean symbolic info for the debugger? No, I mean't the dependency information required by the compiler. > >> I remember RSX-11 in which macro and object libraries were handled by the > >> same librarian tool. > > > RSX-11 is before my time, got any more info on this? > > It was too primitive to be used for Ada. But the idea is basically same. What idea? Same as what? Thanks, Luke.
From: Lucretia on 10 May 2007 13:42 On May 10, 4:34 pm, Stefan Bellon <sbel...(a)sbellon.de> wrote: > Gautier wrote: > > - time stamps to check need of recompilations > > I've always wondered about the focussing on time stamps. I think the way > to do it would be to calculate a hash sum (md5, sha1, ...) on the token > stream without comments. This way you wouldn't have to recompile if you > do layout and commentary changes, and even if you touch the file, you > don't inadvertently trigger a recompilation. > > In fact, this is the idea of the "compilercache" project for C and C++: > It intercepts calls to gcc/g++, builds a hash value on the > concatenation of the command line (minus a few switches that do not > influence code generation) and the preprocessed source and then stores > the resulting object file in the cache with the name of the hash value. > If the same hash value is to be compiled again, it is fetched from the > cache and a lot of compilation time is saved. Another really good idea ;D Thanks, Luke.
From: Lucretia on 10 May 2007 13:48 On May 10, 6:34 pm, Pascal Obry <pas...(a)obry.net> wrote: > Why not play on a C generator for the Ada language ? > > Using ASIS as a start. You then don't have to play with backend > generation. Probably a project that is easier to tackle than a true Ada > compiler even if already quite a bit of work :) > > That's something I wanted to start at some point, and I think now that I > won't have time to start this anytime soon :) > > Just thinking out loud :) No, this is something I'm not that interested in doing as I do want to play with other parts of the compiler as well. Thanks, Luke.
From: Lucretia on 10 May 2007 14:06 On May 10, 6:39 pm, Lucretia <lucret...(a)lycos.co.uk> wrote: > On May 10, 8:59 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > 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.
From: Dmitry A. Kazakov on 10 May 2007 15:30
On 10 May 2007 11:06:28 -0700, Lucretia wrote: > 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. Yes, this is roughly how I did it. > Now this would make either a recursive compiler, or a compiler with > multiple tasks (if developed in Ada ;D). I did it recursively. There was a stack of contexts, so I put a stub on that stack(s) and called the compiler again, quite simple. > 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. The context of either body cannot include the body of three, only the declaration of. (I don't consider inlining here) > 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. These are two different contexts. The private one refers to the public one. If you kept them apart, you could reduce the number of recompilations. > 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. This is a third context which is needed for separate bodies. > 3) All other compilation units compile down to 1 symbol table. Wait a minute (:-)), there also exist task and protected types, and, well generics. Though the pattern is same. Also, you will probably need special contexts for matching prefix notation (be it damned (:-)), keyed associations, qualified names, aggregates. I mean if you wanted to take the advantage of the approach. In my case I postponed all this stuff until the semantic analysis, but the contexts were needed anyway. > 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. Well, contexts could serve as source of symbolic information, but the debugger needs a lot more stuff. I am not sure if the format should be preserved as-is. Clearly it could be a great advantage, but I cannot say how realistic is that. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |