Hi All, I am finally glad to announce an initial version of my secret experiment, Lowtalk: https://github.com/ronsaldo/lowtalkLowtalk 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, |
that's a crazy amount of work, congrats!
|
In reply to this post by Ronie Salgado
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 <[hidden email]> wrote:
|
In reply to this post by Jimmie Houchin-5
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 <[hidden email]>:
|
Thanks for the reply. On 09/05/2017 05:35 PM, Ronie Salgado
wrote:
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.
Would this also be a good way to do mobile, iOS and Android apps?
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.
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
|
In reply to this post by Ronie Salgado
On Thu, Aug 31, 2017 at 12:05 AM, Ronie Salgado <[hidden email]> wrote:
This sounds very cool.
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... which might be interesting to mix with Dennis' work with microcontrollers...
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... cheers -ben
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? (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 <[hidden email]> wrote: >> (although maybe a WebAssembly target might be a better research topic.)On Mon, Sep 18, 2017 at 5:53 AM, Edgar De Cleene <[hidden email]> 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" <[hidden email]> 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 |
In reply to this post by Edgar De Cleene
Hi,
This requires making a backend for ARM. It should be easier to implement than the current backend for x86(-64).
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.
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 <[hidden email]>:
|
> 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 [hidden email] +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
Free forum by Nabble | Edit this page |