Layering in the compiler

[Pippijn van Steenhoven]

Hi,

there is a major flaw in the layering in the Aldor compiler that now
arises, because I am trying to build it for Windows. The layering is, in
theory, like this:

  libport       Portability layer, libc fixups, lowlevel memory
                management.
  libgeneral    Generic data structures such as B-Tree and bit vector,
                garbage collection and memory management.
  libstruct     Compiler data structures such as AST nodes, compiler
                message handling.
  libphases     Compiler phases (foam generation, optimisation, code
                generation (C, Lisp))
  libtoplevel   Compiler driver code. Command line and -gloop handling.

  aldor         The executable that simply calls compCmd (and in my case:
                sets resource and time limits on UNIX because of the
                endless loop and I have had it running away, eating up
                all memory)

Now, going down the list, each subsequent item on it should only depend
on preceding items. This is not the case. libstruct depends heavily on
libphases. Type inference is in libphases, but type form satisfaction is
in libstruct and uses the inference engine. The foam interpreter is in
libstruct (why?) and uses command line handling from libtoplevel. Also,
part of the runtime library is inside libstruct (output.c is used from
libaldor I think).

I split up the phases into libraries, hoping I could make better use of
them in editors for example, but this horribly breaks on windows. On
Linux and other unix-like systems, there is no problem with keeping
unresolved symbol references in shared objects. The final link step when
linking it all together in "aldor", the executable, will find and resolve
all references.
Windows DLLs need to know at link time _of each dll_ where and how
(import libraries) the referenced symbols are defined. So, mutual
dependencies are impossible.

I can think of a few possibilities to solve this issue:

  1) Merge libstruct, libphases and libtoplevel. This could be done by
     making libstruct and libphases static libraries (.lib/.a) and
     linking them together into libtoplevel as one big library.
  2) Make all libraries static and forget about dynamic linking
     alltogether. Without modifications to the C code generation, the
     generated libraries need to be static on windows. I will probably
     make these modifications, because I don't think it is feasible to
     link each aldor application against a large static library. There
     are definite advantages of static libraries over dynamic ones,
     though, and I have to think about those (libgmp not being required
     for the build is one).
  3) Use runtime dynamic loading (LoadLibrary) to manually find the
     symbols and use function pointers and stub functions for windows. I
     personally think this is a very ugly solution but it is the way most
     other people do it on windows. It is called "the way sane people do
     it".

To the original developers: how was the layering supposed to be? The
aldor output functions are in the compiler structures? Does level 2
really have to depend on level 3? Is there any document on this layering
and how it was planned?

Regards,

Pippijn


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Stephen Watt]

This is a good observation Pipppijn.  The layers used to be clean and
exact, but some maintenance and development over the intervening time
has allowed them to become tangled.   Perhaps by judiciously moving
some functions they could be dis-entangled.

-- Stephen


2008/9/4  <pip88nl@...>:

> Hi,
>
> there is a major flaw in the layering in the Aldor compiler that now
> arises, because I am trying to build it for Windows. The layering is, in
> theory, like this:
>
>  libport       Portability layer, libc fixups, lowlevel memory
>                management.
>  libgeneral    Generic data structures such as B-Tree and bit vector,
>                garbage collection and memory management.
>  libstruct     Compiler data structures such as AST nodes, compiler
>                message handling.
>  libphases     Compiler phases (foam generation, optimisation, code
>                generation (C, Lisp))
>  libtoplevel   Compiler driver code. Command line and -gloop handling.
>
>  aldor         The executable that simply calls compCmd (and in my case:
>                sets resource and time limits on UNIX because of the
>                endless loop and I have had it running away, eating up
>                all memory)
>
> Now, going down the list, each subsequent item on it should only depend
> on preceding items. This is not the case. libstruct depends heavily on
> libphases. Type inference is in libphases, but type form satisfaction is
> in libstruct and uses the inference engine. The foam interpreter is in
> libstruct (why?) and uses command line handling from libtoplevel. Also,
> part of the runtime library is inside libstruct (output.c is used from
> libaldor I think).
>
> I split up the phases into libraries, hoping I could make better use of
> them in editors for example, but this horribly breaks on windows. On
> Linux and other unix-like systems, there is no problem with keeping
> unresolved symbol references in shared objects. The final link step when
> linking it all together in "aldor", the executable, will find and resolve
> all references.
> Windows DLLs need to know at link time _of each dll_ where and how
> (import libraries) the referenced symbols are defined. So, mutual
> dependencies are impossible.
>
> I can think of a few possibilities to solve this issue:
>
>  1) Merge libstruct, libphases and libtoplevel. This could be done by
>     making libstruct and libphases static libraries (.lib/.a) and
>     linking them together into libtoplevel as one big library.
>  2) Make all libraries static and forget about dynamic linking
>     alltogether. Without modifications to the C code generation, the
>     generated libraries need to be static on windows. I will probably
>     make these modifications, because I don't think it is feasible to
>     link each aldor application against a large static library. There
>     are definite advantages of static libraries over dynamic ones,
>     though, and I have to think about those (libgmp not being required
>     for the build is one).
>  3) Use runtime dynamic loading (LoadLibrary) to manually find the
>     symbols and use function pointers and stub functions for windows. I
>     personally think this is a very ugly solution but it is the way most
>     other people do it on windows. It is called "the way sane people do
>     it".
>
> To the original developers: how was the layering supposed to be? The
> aldor output functions are in the compiler structures? Does level 2
> really have to depend on level 3? Is there any document on this layering
> and how it was planned?
>
> Regards,
>
> Pippijn
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIv8juJc+zqGNdDgoRAtRgAJ9aJ3/FE+MLdlfN8FvxKV5unbYtAQCfYjKS
> zcp8fzlF9YIDq/96/lE83v4=
> =MoUA
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Aldor-l mailing list
> Aldor-l@...
> http://aldor.org/mailman/listinfo/aldor-l_aldor.org
>
>

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org