Hi All,
I am finally glad to announce an initial version of my secret experiment, Lowtalk: https://github.com/ronsaldo/lowtalk
Lowtalk is a new Smalltalk dialect that generates relocatable binary object code, that can be linked with any C program or used to generate a standalone executable with the C linker. I am designing Lowtalk as a language for video game developing, where performance and multi-threading support is important. The Lowtalk compiler is completely written in Pharo.
The main features of Lowtalk are the following: - The compiler is actually a meta circular evaluator, whose features are used for bootstraping the Lowtalk kernel. - The Lowtalk object model, including the layout of the objects is defined in the language itself. - Direct interface with C. There is an almost 1:1 mapping between the Lowtalk native types and the C types. There is a syntax extension for calling C functions. -Support for real multi-threading. - The current object model uses automatic reference counting, which is slow, but makes supporting real multi-threading easier. - Immediates are based on the Spur object model. - Partial support for generating debugging information in the DWARF standard. It is possible to place breakpoints and get correct stack traces with gdb.
Lowtalk is on the line of my work with Lowcode, and I am planning on making a Lowtalk backend that uses Lowcode. The Lowtalk type system is almost the same as the one that I described at the paper: Lowcode: Extending Pharo with C Types to Improve Performance
I will make a video later, and a proper demonstration at ESUG.
Best regards, Ronie
that's a crazy amount of work, congrats!
Hello Ronie,
I think this looks very interesting. I just downloaded your paper to read. I look forward to seeing the video of your ESUG demonstration.
What do you believe the best mailing list to list ask questions at some point in the future?
Thanks again for your work on this interesting project.
Jimmie
On 08/30/2017 11:05 AM, Ronie Salgado wrote:
Hi All,
I am finally glad to announce an initial version of my secret experiment, Lowtalk: https://github.com/ronsaldo/lowtalk
Lowtalk is a new Smalltalk dialect that generates relocatable binary object code, that can be linked with any C program or used to generate a standalone executable with the C linker. I am designing Lowtalk as a language for video game developing, where performance and multi-threading support is important. The Lowtalk compiler is completely written in Pharo.
The main features of Lowtalk are the following:
- The compiler is actually a meta circular evaluator, whose features are
used for bootstraping the Lowtalk kernel.
- The Lowtalk object model, including the layout of the objects is
defined in the language itself.
- Direct interface with C. There is an almost 1:1 mapping between the
Lowtalk native types and the C types. There is a syntax extension for calling C functions. -Support for real multi-threading.
- The current object model uses automatic reference counting, which is
slow, but makes supporting real multi-threading easier.
- Immediates are based on the Spur object model.
- Partial support for generating debugging information in the DWARF
standard. It is possible to place breakpoints and get correct stack traces with gdb.
Lowtalk is on the line of my work with Lowcode, and I am planning on making a Lowtalk backend that uses Lowcode. The Lowtalk type system is almost the same as the one that I described at the paper: Lowcode: Extending Pharo with C Types to Improve Performance
I will make a video later, and a proper demonstration at ESUG.
Best regards, Ronie
Definitely nice.
Is this 64-bit?
Phil
On Tue, Sep 5, 2017 at 5:02 PM, Jimmie jlhouchin@gmail.com wrote:
Hello Ronie,
I think this looks very interesting. I just downloaded your paper to read. I look forward to seeing the video of your ESUG demonstration.
What do you believe the best mailing list to list ask questions at some point in the future?
Thanks again for your work on this interesting project.
Jimmie
On 08/30/2017 11:05 AM, Ronie Salgado wrote:
Hi All,
I am finally glad to announce an initial version of my secret experiment, Lowtalk: https://github.com/ronsaldo/lowtalk
Lowtalk is a new Smalltalk dialect that generates relocatable binary object code, that can be linked with any C program or used to generate a standalone executable with the C linker. I am designing Lowtalk as a language for video game developing, where performance and multi-threading support is important. The Lowtalk compiler is completely written in Pharo.
The main features of Lowtalk are the following:
- The compiler is actually a meta circular evaluator, whose features are
used for bootstraping the Lowtalk kernel.
- The Lowtalk object model, including the layout of the objects is
defined in the language itself.
- Direct interface with C. There is an almost 1:1 mapping between the
Lowtalk native types and the C types. There is a syntax extension for calling C functions. -Support for real multi-threading.
- The current object model uses automatic reference counting, which is
slow, but makes supporting real multi-threading easier.
- Immediates are based on the Spur object model.
- Partial support for generating debugging information in the DWARF
standard. It is possible to place breakpoints and get correct stack traces with gdb.
Lowtalk is on the line of my work with Lowcode, and I am planning on making a Lowtalk backend that uses Lowcode. The Lowtalk type system is almost the same as the one that I described at the paper: Lowcode: Extending Pharo with C Types to Improve Performance
I will make a video later, and a proper demonstration at ESUG.
Best regards, Ronie
Hello Jimmie,
On ESUG I only presented it for the innovation award. There is no scientific paper on Lowtalk itself yet, because most of the work on this front end is recently. I am probably submitting.
There is still the possibility on changing the syntax and some of mechanism that are used in Lowtalk, Currently I am showing what is possible to do.
What do you believe the best mailing list to list ask questions at some
point in the future?
This is a good question. Currently I do not know. This is an early work, and there is still a lot more to do. We now have to discuss about how to proceed. I have to discuss properly with Eliot about how to keep proceeding. I am reusing some of his techniques for implementing some parts such as the stack to context mapping, and immediates objects.
Lowtalk is currently Pharo only, and it is completely standalone from the OpenSmalltalk VM. However, I am going to make a backend for Lowtalk that uses Lowcode to be able to use it inside the current image environment. Both use cases are interesting: - standalone executables for embedding and soft realtime (videogames). - keeping the current VM and reusing the in-image environment allows to use the full power of the Pharo/Squeak environment. In this case, Lowtalk can be used for getting a performance boost in numerical intensive software loops (e.g: matrix multiplication, typically an O(n^3) algorithm), without having to resort to the FFI for calling externally compiled C code.
I want to use Lowtalk in Woden 2 exactly for the second use case. Currently in Woden 2 I am using the language described in the Lowcode paper. Because the type system introduces dependencies on the compilation order, it does not behave well with Monticello which I had to patch in Woden 2. With Lowtalk I am solving that problem by using standard text files, and multiple semantic analysis passes over the AST to define circular types lazily. for example:
Structure named: #LinkedListNode slots: { #next => (LinkedListNode pointer). #value => (Void pointer) }.
Best regards, Ronie
2017-09-05 17:02 GMT+02:00 Jimmie jlhouchin@gmail.com:
Hello Ronie,
I think this looks very interesting. I just downloaded your paper to read. I look forward to seeing the video of your ESUG demonstration.
What do you believe the best mailing list to list ask questions at some point in the future?
Thanks again for your work on this interesting project.
Jimmie
On 08/30/2017 11:05 AM, Ronie Salgado wrote:
Hi All,
I am finally glad to announce an initial version of my secret experiment, Lowtalk: https://github.com/ronsaldo/lowtalk
Lowtalk is a new Smalltalk dialect that generates relocatable binary object code, that can be linked with any C program or used to generate a standalone executable with the C linker. I am designing Lowtalk as a language for video game developing, where performance and multi-threading support is important. The Lowtalk compiler is completely written in Pharo.
The main features of Lowtalk are the following:
- The compiler is actually a meta circular evaluator, whose features are
used for bootstraping the Lowtalk kernel.
- The Lowtalk object model, including the layout of the objects is
defined in the language itself.
- Direct interface with C. There is an almost 1:1 mapping between the
Lowtalk native types and the C types. There is a syntax extension for calling C functions. -Support for real multi-threading.
- The current object model uses automatic reference counting, which is
slow, but makes supporting real multi-threading easier.
- Immediates are based on the Spur object model.
- Partial support for generating debugging information in the DWARF
standard. It is possible to place breakpoints and get correct stack traces with gdb.
Lowtalk is on the line of my work with Lowcode, and I am planning on making a Lowtalk backend that uses Lowcode. The Lowtalk type system is almost the same as the one that I described at the paper: Lowcode: Extending Pharo with C Types to Improve Performance
I will make a video later, and a proper demonstration at ESUG.
Best regards, Ronie
Thanks for the reply.
On 09/05/2017 05:35 PM, Ronie Salgado wrote:
Hello Jimmie,
On ESUG I only presented it for the innovation award. There is no scientific paper on Lowtalk itself yet, because most of the work on this front end is recently. I am probably submitting.
There is still the possibility on changing the syntax and some of mechanism that are used in Lowtalk, Currently I am showing what is possible to do.
What do you believe the best mailing list to list ask questions at some point in the future?This is a good question. Currently I do not know. This is an early work, and there is still a lot more to do. We now have to discuss about how to proceed. I have to discuss properly with Eliot about how to keep proceeding. I am reusing some of his techniques for implementing some parts such as the stack to context mapping, and immediates objects.
Maybe it is unique enough that it would need its own mailing list at some point. Unless it became potentially a part of Pharo and thus suitable for pharo-dev.
Lowtalk is currently Pharo only, and it is completely standalone from the OpenSmalltalk VM. However, I am going to make a backend for Lowtalk that uses Lowcode to be able to use it inside the current image environment. Both use cases are interesting:
- standalone executables for embedding and soft realtime (videogames).
Would this also be a good way to do mobile, iOS and Android apps?
- keeping the current VM and reusing the in-image environment allows
to use the full power of the Pharo/Squeak environment. In this case, Lowtalk can be used for getting a performance boost in numerical intensive software loops (e.g: matrix multiplication, typically an O(n^3) algorithm), without having to resort to the FFI for calling externally compiled C code.
I am definitely interested in this. I am interested in arrays of numbers and doing calculations on those numbers. I was thinking that I would be needing to code this in C and call from UFFI. I read your message and I thought that it meant I could code in Lowtalk and then call the new library via UFFI.
So, what I understand here is that I can code in Lowtalk for the Lowcode backend and not require UFFI? At least at some point in the future. That sounds awesome.
I want to use Lowtalk in Woden 2 exactly for the second use case. Currently in Woden 2 I am using the language described in the Lowcode paper. Because the type system introduces dependencies on the compilation order, it does not behave well with Monticello which I had to patch in Woden 2. With Lowtalk I am solving that problem by using standard text files, and multiple semantic analysis passes over the AST to define circular types lazily. for example:
Structure named: #LinkedListNode slots: { #next => (LinkedListNode pointer). #value => (Void pointer) }.
Ok. I was confused in my brief look at GitHub as to whether we were programming in the image on with a text editor. It would be nice if at some point it could be done from the image. Even if it is a with a new editor (possible from the new moldable work) understanding Lowtalk and tools to do compilation.
Possibilities are interesting.
Thanks again. I look forward to seeing what happens.
Jimmie
Best regards, Ronie
2017-09-05 17:02 GMT+02:00 Jimmie <jlhouchin@gmail.com mailto:jlhouchin@gmail.com>:
Hello Ronie, I think this looks very interesting. I just downloaded your paper to read. I look forward to seeing the video of your ESUG demonstration. What do you believe the best mailing list to list ask questions at some point in the future? Thanks again for your work on this interesting project. Jimmie On 08/30/2017 11:05 AM, Ronie Salgado wrote: Hi All, I am finally glad to announce an initial version of my secret experiment, Lowtalk: https://github.com/ronsaldo/lowtalk <https://github.com/ronsaldo/lowtalk> Lowtalk is a new Smalltalk dialect that generates relocatable binary object code, that can be linked with any C program or used to generate a standalone executable with the C linker. I am designing Lowtalk as a language for video game developing, where performance and multi-threading support is important. The Lowtalk compiler is completely written in Pharo. The main features of Lowtalk are the following: - The compiler is actually a meta circular evaluator, whose features are used for bootstraping the Lowtalk kernel. - The Lowtalk object model, including the layout of the objects is defined in the language itself. - Direct interface with C. There is an almost 1:1 mapping between the Lowtalk native types and the C types. There is a syntax extension for calling C functions. -Support for real multi-threading. - The current object model uses automatic reference counting, which is slow, but makes supporting real multi-threading easier. - Immediates are based on the Spur object model. - Partial support for generating debugging information in the DWARF standard. It is possible to place breakpoints and get correct stack traces with gdb. Lowtalk is on the line of my work with Lowcode, and I am planning on making a Lowtalk backend that uses Lowcode. The Lowtalk type system is almost the same as the one that I described at the paper: Lowcode: Extending Pharo with C Types to Improve Performance I will make a video later, and a proper demonstration at ESUG. Best regards, Ronie
On Thu, Aug 31, 2017 at 12:05 AM, Ronie Salgado roniesalg@gmail.com wrote:
Hi All,
I am finally glad to announce an initial version of my secret experiment, Lowtalk: https://github.com/ronsaldo/lowtalk
Lowtalk is a new Smalltalk dialect that generates relocatable binary object code, that can be linked with any C program or used to generate a standalone executable with the C linker. I am designing Lowtalk as a language for video game developing, where performance and multi-threading support is important. The Lowtalk compiler is completely written in Pharo.
This sounds very cool.
The main features of Lowtalk are the following:
- The compiler is actually a meta circular evaluator, whose features are
used for bootstraping the Lowtalk kernel.
Just to clarify, I guess you mean you provide a native machine code compiler, so a separate C compiler step is not required?
With the right CPU model, would Lowtalk facilitate generating native microcontroller machine code from Smalltalk code, for devices like... https://www.adafruit.com/product/3403 https://www.adafruit.com/product/3501 which might be interesting to mix with Dennis' work with microcontrollers...
http://forum.world.st/Ann-PharoThings-a-live-programming-IoT-platform-based-...
- The Lowtalk object model, including the layout of the objects is defined
in the language itself.
- Direct interface with C. There is an almost 1:1 mapping between the
Lowtalk native types and the C types. There is a syntax extension for calling C functions.
How do you rate generating LLVM intermediate representation (IR) ? How otherwise do low level optimisations come into your concept? I couple of articles I found interesting... https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/
https://stackoverflow.com/questions/15150116/translation-to-llvm-ir-directly...
cheers -ben
-Support for real multi-threading.
- The current object model uses automatic reference counting, which is
slow, but makes supporting real multi-threading easier.
- Immediates are based on the Spur object model.
- Partial support for generating debugging information in the DWARF
standard. It is possible to place breakpoints and get correct stack traces with gdb.
Lowtalk is on the line of my work with Lowcode, and I am planning on making a Lowtalk backend that uses Lowcode. The Lowtalk type system is almost the same as the one that I described at the paper: Lowcode: Extending Pharo with C Types to Improve Performance
I will make a video later, and a proper demonstration at ESUG.
Best regards, Ronie
P.S. @Eliot, et al... I found it interesting that several alternate calling conventions are implemented for LLVM. Could such a thing be useful to support Smalltalk better, and be a useful research topic for someone?
http://clang-developers.42468.n3.nabble.com/RFC-Implementing-the-Swift-calli... http://lists.llvm.org/pipermail/llvm-dev/2016-June/101338.html
(although maybe a WebAssembly target might be a better research topic.)
We are studying WebAssembly and have in the hands a Cuis fork with all necessary for have Smalltalk both sides of Web 2.0. This .image for server side and Amber and Morphic.js on the client side. So I glad to share experiments and feedback of my students and me on Smalltalk, WebAssembly and ways on made Web 2.0 nice and fast.
Edgar @morplenauta
On 17 Sep 2017, at 11:44, Ben Coman btc@openinworld.com wrote:
(although maybe a WebAssembly target might be a better research topic.)
On 17 Sep 2017, at 11:44, Ben Coman btc@openinworld.com wrote:
(although maybe a WebAssembly target might be a better research topic.)On Mon, Sep 18, 2017 at 5:53 AM, Edgar De Cleene
edgardec2005@gmail.com wrote:
We are studying WebAssembly and have in the hands a Cuis fork with all necessary for have Smalltalk both sides of Web 2.0. This .image for server side and Amber and Morphic.js on the client side. So I glad to share experiments and feedback of my students and me on Smalltalk, WebAssembly and ways on made Web 2.0 nice and fast.
That is interesting hear of some progress. My understanding/expectation of WebAssembly is for the OpenSmalltalk VM (at least the StackInterpreter) to run standard Cuis/Pharo/Squeak images in client web browsers (minus a few plugins). What are your plans to experiment in that direction? Or do you prioritise a different approach?
cheers -ben
Right now we are collecting all we found about WebAssembly , you could see here http://www.pearltrees.com/edgardec/webassembly/id17669549 I try to have a "live Book and Playground" for Smalltalk,WebAssembly and Web 2.0, based in the .image for quick prototyping.
Currently reading the tons of documents and teaching to the .image to read and dissasemble the .wasm files you get with WABT https://cdn.rawgit.com/WebAssembly/wabt/7e56ca56/demo/wast2wasm/
I hope for Smalltalks in La Plata,Argentina this year we have something to show.
On 9/17/17, 22:48, "Ben Coman" btc@openinworld.com wrote:
That is interesting hear of some progress. My
understanding/expectation of
WebAssembly is for the OpenSmalltalk VM
(at least the StackInterpreter) to run
standard Cuis/Pharo/Squeak
images in client web browsers (minus a few
plugins). What are your
plans to experiment in that direction? Or do you
prioritise a
different approach?
cheers -ben
Hi,
Just to clarify, I guess you mean you provide a native machine
code compiler, so a separate C compiler step is not required?
With the right CPU model, would Lowtalk facilitate generating native microcontroller machine code from Smalltalk code, for devices like... https://www.adafruit.com/product/3403 https://www.adafruit.com/product/3501 which might be interesting to mix with Dennis' work with microcontrollers... http://forum.world.st/Ann-PharoThings-a-live-programming-IoT-platform- based-on-Pharo-td4964090.html#a4964103
This requires making a backend for ARM. It should be easier to implement than the current backend for x86(-64).
How do you rate generating LLVM intermediate representation (IR) ? How otherwise do low level optimisations come into your concept? I couple of articles I found interesting... https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/ https://stackoverflow.com/questions/15150116/translation-to-llvm-ir- directly-or-via-c-clang
cheers -ben
My intermediate representation is based on the one used by LLVM. The problem of actually using LLVM, is that it is necessary to extend LLVM with custom calling conventions to be able to support two smalltalk features: thisContext (via the stack to context mapping), and non-local returns. By using a custom calling convention, it is possible to support these features in the same way that is made by Cog. However, adding the calling convention requires writing code in C++ to extend LLVM.
P.S. @Eliot, et al...
I found it interesting that several alternate calling conventions are implemented for LLVM. Could such a thing be useful to support Smalltalk better, and be a useful research topic for someone? http://clang-developers.42468.n3.nabble.com/RFC-Implementing-the-Swift- calling-convention-in-LLVM-and-Clang-td4050248.html http://lists.llvm.org/pipermail/llvm-dev/2016-June/101338.html
(although maybe a WebAssembly target might be a better research topic.)
We are studying WebAssembly and have in the hands a Cuis fork with all
necessary for have Smalltalk both sides of Web 2.0. This .image for server side and Amber and Morphic.js on the client side. So I glad to share experiments and feedback of my students and me on Smalltalk, WebAssembly and ways on made Web 2.0 nice and fast.
Edgar @morplenauta
It seems that everybody is interested on WebAssembly, and having Smalltalk on the Web. I checked the WebAssembly spec and I see that it is not possible to support Smalltalk completely in an efficient way. There is no way for accessing the stack to implement thisContext. There is also no way for doing setjmp/longjmp directly on webassembly to implement non-local returns and Smalltalk exceptions. By doing a goggle search, it seems that the behavior of setjmp/longjmp is simulated by wrapping a method in javascript code, and using javascript exception handling for doing the longjmp.
Best regards, Ronie
2017-09-17 23:53 GMT+02:00 Edgar De Cleene edgardec2005@gmail.com:
We are studying WebAssembly and have in the hands a Cuis fork with all necessary for have Smalltalk both sides of Web 2.0. This .image for server side and Amber and Morphic.js on the client side. So I glad to share experiments and feedback of my students and me on Smalltalk, WebAssembly and ways on made Web 2.0 nice and fast.
Edgar @morplenauta
On 17 Sep 2017, at 11:44, Ben Coman btc@openinworld.com wrote:
(although maybe a WebAssembly target might be a better research topic.)
It seems that everybody is interested in WebAssembly, and having Smalltalk on the Web.
We do have Smalltalk on the Web, with SqueakJS.
https://squeak.js.org https://caffeine.js.org
-C
-- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
Bernardo Ezequiel Contreras -
Craig Latta -
Edgar De Cleene -
Edgar J. De Cleene
-
Jimmie -
Jimmie Houchin
-
phil＠highoctane.be -
Ronie Salgado