Re: Implementing an Ada compiler and libraries.

[Lucretia <lucretia9@lycos.co.uk>]

On May 10, 6:39 pm, Lucretia <lucret...@lycos.co.uk> wrote:
> On May 10, 8:59 am, "Dmitry A. Kazakov" <mail...@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.