[Vm-dev] [ANN] Lowtalk, a new Smalltalk dialect that could eventually replace Slang

Ronie Salgado roniesalg at gmail.com
Mon Sep 18 12:58:27 UTC 2017


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 at 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 at openinworld.com> wrote:
>
> (although maybe a WebAssembly target might be a better research topic.)
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170918/ad447d90/attachment.html>


More information about the Vm-dev mailing list