Hello Dimitris,

The package named 'VMMaker-Translation to C' does what you are looking for. It translates Smalltalk source code to Smalltalk AST, then Smalltalk AST to Slang AST, then perform some optimizations on Slang AST, then writes the C code. The slang AST is all the class with names starting with T in this package. The CCodeGenerator is the class responsible for C code generation from slang AST. A closed world assumption allows the generator to do inlining efficiently and compile to direct function call, hence C code generation of a single method can be done only by parsing all the slang method needed for C compilation. The closed world is defined according to different settings such as which memory manager or which jit back end is used. There are no polymorphism in the generated c code, though there are polymorphism in Slang, for example all the memory managers are polymorphic with each other, but you have to pick one of them for C compilation. Super sends acts as macro replacements. There are no such things as mapping Smalltalk classes to C++ classes, it's more about compiling a huge pack of functions all together.

The other packages of VM Maker are related to the interpreter, the JIT, the Memory manager and the simulator. Code used exclusively for simulation or testing purpose can be Smalltalk, but most code here is in Slang.

There are documentation about the VM in general but I don't think there is documentation specifically about slang itself. Slang is meant to compile the VM and only the VM, hence both projects are tied together. It does not feel like it's a good idea to extract the C code generator as some things were hacked in the generator to make VM compilation work, while the VM code was hacked to work with the generator. In fact, each time we want to do something that is not possible in the VM, we hack either the VM code or the slang generator depending on which solution implies the least time consumption over the next few years.

You have to know that the Slang to C generation is, in my opinion, the worst code of the whole VM packages.

This is the kind of script I use in Squeak to generate the C code for a single smalltalk method and check if everything is correct, I guess it works in Pharo, as you can see, the compilation process is dependent on VM compilation, as you have to precise which JIT and memory manager to use to define correctly the closed world that will be generated and hence what function you can call or inline :

I'd recommend you to ask question about this topic on the VM mailing list (http://lists.squeakfoundation.org/mailman/listinfo/vm-dev) because few people in the Pharo community have a good understanding of Slang, and the ones whodo are also on vm-dev.

Have fun :-)