[ANN] Sysmel, another experimental low-level language implemented in Pharo
Hi All, I am finally announcing an initial release of my new experimental low-level programming language which I am calling Sysmel (For SYStem MEtaprogramming Language). GitHub Page: https://github.com/ronsaldo/sysmel Short native game demo: https://www.youtube.com/watch?v=tRoPMbPvqH0 Sysmel is designed to be a flexible language, and a flexible compiler front-end. The support for garbage collection in Sysmel is an optional feature by design, and the support for dynamic objects and dynamic message lookup it is also optional. If garbage collection is disabled, the code written in Sysmel is mostly equivalent to C/C++ code (only single inheritance is supported for now), but with a hybrid syntax between Smalltalk and C++. For the final code generation I am using my custom SSA intermediate representation (the same one that I used in Lowtalk, and in) which it is currently tested with the following two backends: - LLVM textual IR backend. This is used for generating native object files by reusing the LLVM infrastructure. This backend also supports emitting DWARF debugging information so the resulting programs can be debugged with gdb. - Spir-V backend, for generating shaders for Vulkan and executing them in the GPU. One of the objectives of Sysmel is to support the full Smalltalk object model without a VM and with real multi-threading support. So far message lookup is already implemented, but there is still many basic primitives missing, and the implementation of a proper GC that allows implementing #allInstances and #become: . As a quick workaround, currently only the Boehm conservative GC is supported for having an initially working environment. In the near future, Woden Engine will adopt Sysmel at least as its shading language for programming the GPU. In a farther future, a higher performance version of the Woden Engine will be made by using Sysmel, mostly because it seems to be much easier to support real multi-threading in Sysmel by making a completely new system. I am also re-implementing my previous experiment for converting Pharo block closures into shaders by reusing the Sysmel intermediate level AST, and its type inference machinery. The current version of this new Block -> to Shader infrastructure can only perform basic Map and Reduce operations with blocks that do not define local variables (they will be supported in a future version) in linear arrays. Best regards, Ronie
Nice work! Doru
On Jan 9, 2020, at 4:59 AM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hi All,
I am finally announcing an initial release of my new experimental low-level programming language which I am calling Sysmel (For SYStem MEtaprogramming Language).
GitHub Page: https://github.com/ronsaldo/sysmel Short native game demo: https://www.youtube.com/watch?v=tRoPMbPvqH0
Sysmel is designed to be a flexible language, and a flexible compiler front-end. The support for garbage collection in Sysmel is an optional feature by design, and the support for dynamic objects and dynamic message lookup it is also optional. If garbage collection is disabled, the code written in Sysmel is mostly equivalent to C/C++ code (only single inheritance is supported for now), but with a hybrid syntax between Smalltalk and C++.
For the final code generation I am using my custom SSA intermediate representation (the same one that I used in Lowtalk, and in) which it is currently tested with the following two backends: - LLVM textual IR backend. This is used for generating native object files by reusing the LLVM infrastructure. This backend also supports emitting DWARF debugging information so the resulting programs can be debugged with gdb. - Spir-V backend, for generating shaders for Vulkan and executing them in the GPU.
One of the objectives of Sysmel is to support the full Smalltalk object model without a VM and with real multi-threading support. So far message lookup is already implemented, but there is still many basic primitives missing, and the implementation of a proper GC that allows implementing #allInstances and #become: . As a quick workaround, currently only the Boehm conservative GC is supported for having an initially working environment.
In the near future, Woden Engine will adopt Sysmel at least as its shading language for programming the GPU. In a farther future, a higher performance version of the Woden Engine will be made by using Sysmel, mostly because it seems to be much easier to support real multi-threading in Sysmel by making a completely new system.
I am also re-implementing my previous experiment for converting Pharo block closures into shaders by reusing the Sysmel intermediate level AST, and its type inference machinery. The current version of this new Block -> to Shader infrastructure can only perform basic Map and Reduce operations with blocks that do not define local variables (they will be supported in a future version) in linear arrays.
Best regards, Ronie
-- feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."
Ronie Salgado wrote
In a farther future, a higher performance version of the Woden Engine will be made by using Sysmel, mostly because it seems to be much easier to support real multi-threading in Sysmel by making a completely new system.
Congrats! But... sad that Pharo may eventually lose Woden. Is there no other way? E.g. optimizing? Also, do you think "yet another programming language" to learn will discourage a wide audience for Woden? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
In a farther future, a higher performance version of the Woden Engine will be made by using Sysmel, mostly because it seems to be much easier to support real multi-threading in Sysmel by making a completely new system.
Congrats! But... sad that Pharo may eventually lose Woden. Is there no other way? E.g. optimizing? Also, do you think "yet another programming language" to learn will discourage a wide audience for Woden?
Well, the alternative is C++ which is a lot of worse. But Pharo will keep being the scripting language for Woden, but probably a much more minimalistic and "embedded" version of Pharo in the long term. I am designing Sysmel in a way so it is easy to compile standard Pharo code into the Sysmel run time. El jue., 9 ene. 2020 a las 17:18, Sean P. DeNigris (<sean@clipperadams.com>) escribió:
Ronie Salgado wrote
In a farther future, a higher performance version of the Woden Engine will be made by using Sysmel, mostly because it seems to be much easier to support real multi-threading in Sysmel by making a completely new system.
Congrats! But... sad that Pharo may eventually lose Woden. Is there no other way? E.g. optimizing? Also, do you think "yet another programming language" to learn will discourage a wide audience for Woden?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On Thu, 9 Jan 2020 at 12:00, Ronie Salgado <roniesalg@gmail.com> wrote:
Hi All,
I am finally announcing an initial release of my new experimental low-level programming language which I am calling Sysmel (For SYStem MEtaprogramming Language).
GitHub Page: https://github.com/ronsaldo/sysmel Short native game demo: https://www.youtube.com/watch?v=tRoPMbPvqH0
Sysmel is designed to be a flexible language, and a flexible compiler front-end. The support for garbage collection in Sysmel is an optional feature by design, and the support for dynamic objects and dynamic message lookup it is also optional. If garbage collection is disabled, the code written in Sysmel is mostly equivalent to C/C++ code (only single inheritance is supported for now), but with a hybrid syntax between Smalltalk and C++.
For the final code generation I am using my custom SSA intermediate representation (the same one that I used in Lowtalk, and in) which it is currently tested with the following two backends: - LLVM textual IR backend. This is used for generating native object files by reusing the LLVM infrastructure. This backend also supports emitting DWARF debugging information so the resulting programs can be debugged with gdb. - Spir-V backend, for generating shaders for Vulkan and executing them in the GPU.
I am also re-implementing my previous experiment for converting Pharo block closures into shaders by reusing the Sysmel intermediate level AST, and its type inference machinery.
Side note, for academics needing interesting final projects for students, one would be have this infrastructure for Pharo blocks generate/load code for the Programmable Real-time Units on a Beaglebone - useful for a dynamically programmable hard-real-time system for robotics. https://www.ti.com/lit/ug/tidu461/tidu461.pdf https://www.youtube.com/watch?v=B1DssoXzUXw https://www.youtube.com/results?search_query=beagleboard+pru cheers -ben
participants (4)
-
Ben Coman -
Ronie Salgado -
Sean P. DeNigris -
Tudor Girba