| 1 | The idea for writing a new compiler came from the need to a better |
|---|
| 2 | separation of the compilation process and the compilation |
|---|
| 3 | runtime. This is needed because eventually, the runtime for each |
|---|
| 4 | platform may be completely different from the others. This way this |
|---|
| 5 | new compiler will define an API that the compiler can call to the |
|---|
| 6 | Runtime virtual machine in a way to make it more pluggable. |
|---|
| 7 | |
|---|
| 8 | KindaPerl6::VirtualMachine is the namespace for the API that is |
|---|
| 9 | called. The calling convention for this namespace follows the calling |
|---|
| 10 | convention of the "host" implementation, so, if the Perl5 |
|---|
| 11 | implementation uses a dispatch mechanism, the |
|---|
| 12 | KindaPerl6::VirtualMachine::Perl5 implementation should use that. On |
|---|
| 13 | the other hand in Parrot, it will probably use the Parrot's calling |
|---|
| 14 | convention. |
|---|
| 15 | |
|---|
| 16 | The same way that there are different VM implementations, the Emitting |
|---|
| 17 | process is also pluggable itself, allowing the writing of a |
|---|
| 18 | cross-compiler. This way, the "Perl5", "Perl5rx" and "Parrot" |
|---|
| 19 | implementations are considered "architecture". |
|---|
| 20 | |
|---|
| 21 | The compiler plugins, like alternative rule compilation must be |
|---|
| 22 | available in the host architecture to be used. This plugins may add |
|---|
| 23 | opaque data to the compilation process which will be recognized by the |
|---|
| 24 | emitter phase. |
|---|
| 25 | |
|---|
| 26 | The following diagram illustrates the process: |
|---|
| 27 | |
|---|
| 28 | <COMPILATION_PROCESS.dia> |
|---|
| 29 | |
|---|
| 30 | Files: |
|---|
| 31 | |
|---|
| 32 | YAP6::Compiler - This is the main class, that contains the code |
|---|
| 33 | to initiate the compilation process. By default it will use all the |
|---|
| 34 | options used to compile it. It's the entrance to define also which |
|---|
| 35 | plugins are loaded and which target will be used. |
|---|
| 36 | |
|---|
| 37 | YAP6::VirtualMachine - This is the API to access the runtime not |
|---|
| 38 | only in the compilation phase, but also during code execution. This is |
|---|
| 39 | a procedural interface to the VM. Only one is available at a time and |
|---|
| 40 | contains all the runtime information needed. Symbol definitions are |
|---|
| 41 | all made here. This symbol definitions can point to low-level defined |
|---|
| 42 | objects, to compiled objects or even to nodes in the AST. For targets |
|---|
| 43 | that allow bytecode generation, the runtime needs to be serializable. |
|---|
| 44 | |
|---|
| 45 | YAP6::AST - This is the OO representatino of the Abstract Syntax |
|---|
| 46 | Tree inside the compiler. This should be back-end independent. And |
|---|
| 47 | every target should be able to run it instantly or generate code for it. |
|---|
