Aml/System Plans

A side note: I indefinitely postponed any development of the Aml# and Aml#/System "dialects". It does not make much sense to create these at the moment, and once Aml Core is a viable SDK, then maybe, maybe.

The current plan for Aml/System is as follows:

1. Write a Rust program that would be the stage 0 Aml/System compiler. It does not have to do much, it does not need to compile all of Aml/System features and libraries, just the most basic things needed for a stage 1 compiler to compile. For that, decide what is this minimal subset of Aml/System. Probably the only way to do that is to simultaneously write a stage 1 compiler. (This is where we’re at now.)
2. Write a stage 1 compiler, using a subset of Aml/System. This compiler will have to be able to compile every Aml/System feature, including any possible libraries, and including itself. 
3. Write a stage 2 compiler, using the full feature set of Aml/System. This compiler will then be completely self-hosted, being able to compile itself (while the first build will be compiled by a stage 1 compiler). It’s questionable whether this step is necessary, or if there will have to be more stages to incrementally get to a stage N compiler, where N is the final compiler stage written in the same language that it compiles. 

It is possible that in between writing a stage 1 compiler and a stage 2 compiler, there will be a switch in technology, regarding what the intermediary output would be. Compilers up to stage 1 will very likely just transpile to C or C++ (not sure yet), depending on the ways of the clang and msvc, while stage 2 may drop the C/C++ intermediary form and go right for Aml/System IR to LLVM IR transformation, which is something that can happen while already happily building runtime for Aml/Core using a stage 1 compiler, because the runtime does not care if its compiler is a self-hosted one or nah. 

The dependency on cc, gcc or link.exe is something Aml/System is not likely to get rid of while targeting any of the currently serving Operating Systems (until plan-89 comes to life). 

Note that switching from a clang/msvc backed program building and moving to LLVM IR code generation presents more challenges than it may seem: 

• Learn LLVM IR, while LLVM itself is in active development and may change in BC-breaking manner anytime. The solution is obviously to fork it and only merge changes when ready. 
• Learn how to interoperate with the libc etc. from within LLVM IR. 
• Learn code optimizations, since clang/msvc will no longer do that for us. 
• Learn archive packaging (heard some rumours that the Windows archive tool has some troubles with non-object members of archive files). Might need to use llvm-ar for that instead. 
• Also, true not just for this switch, but – support debugging interfaces. Aml/Core will have a very much different runtime from Aml/System, and we can design debugging interface for Aml/Core ourselves, since probably nobody would ever use an existing one for the job – also, remember that the runtime is also very much different from the regular stack-based runtimes of other high-level languages. Unlike the runtime of Aml/System, unfortunately. Maybe plan-89 will allow fancier code to be written in Aml/System, we’ll see. 

P.S.: Aml/System, as well as Aml/Core and all of its docs are written as open source under the MIT license, so you can use it however you wish to, but – it would be really appreciated if you could just join the efforts and help out with the job.