[Aldor-l] Layering in the compiler

[pip88nl at gmail.com]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://aldor.org/pipermail/aldor-l_aldor.org/attachments/20080904/78f02e8b/attachment.bin