<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 31, 2017 at 12:05 AM, Ronie Salgado <span dir="ltr"><<a href="mailto:roniesalg@gmail.com" target="_blank">roniesalg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div dir="ltr"><div><div><div><div>Hi All,<br><br></div>I am finally glad to announce an initial version of my secret experiment, Lowtalk: <a href="https://github.com/ronsaldo/lowtalk" target="_blank">https://github.com/ronsaldo/<wbr>lowtalk</a><br></div><div><br></div><div>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.<br></div></div></div></div></blockquote><div><br></div><div>This sounds very cool.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div></div><div><br></div><div>The main features of Lowtalk are the following:</div><div>- The compiler is actually a meta circular evaluator, whose features are used for bootstraping the Lowtalk kernel.</div></div></div></div></blockquote><div><br></div><div>Just to clarify, I guess you mean you provide a native machine code compiler, so a separate C compiler step is not required?</div><div><br></div><div>With the right CPU model, would Lowtalk facilitate generating native microcontroller machine code from Smalltalk code, for devices like...</div><div>   <a href="https://www.adafruit.com/product/3403">https://www.adafruit.com/product/3403</a></div><div>   <a href="https://www.adafruit.com/product/3501">https://www.adafruit.com/product/3501</a></div><div>which might be interesting to mix with Dennis' work with microcontrollers...</div><div>  <a href="http://forum.world.st/Ann-PharoThings-a-live-programming-IoT-platform-based-on-Pharo-td4964090.html#a4964103">http://forum.world.st/Ann-PharoThings-a-live-programming-IoT-platform-based-on-Pharo-td4964090.html#a4964103</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div>- The Lowtalk object model, including the layout of the objects is defined in the language itself.</div><div>- 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.<br></div></div></div></div></blockquote><div><br></div><div><div>How do you rate generating LLVM intermediate representation (IR) ?  How otherwise do low level optimisations come into your concept? <br></div><div>I couple of articles I found interesting...</div><div>  <a href="https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/">https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/</a><br></div><div>  <a href="https://stackoverflow.com/questions/15150116/translation-to-llvm-ir-directly-or-via-c-clang">https://stackoverflow.com/questions/15150116/translation-to-llvm-ir-directly-or-via-c-clang</a><br></div></div><div><br></div><div>cheers -ben<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div></div><div>-Support for real multi-threading.<br></div><div>- The current object model uses automatic reference counting, which is slow, but makes supporting real multi-threading easier.</div><div>- Immediates are based on the Spur object model.</div><div>- Partial support for generating debugging information in the DWARF standard. It is possible to place breakpoints and get correct stack traces with gdb.<br></div><div><br></div><div>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<br></div></div></div><div><br><div>I will make a video later, and a proper demonstration at ESUG.<br><br></div>Best regards,<br></div>Ronie<br></div>
<br></blockquote></div><br></div><div class="gmail_extra">P.S. @Eliot, et al...</div><div class="gmail_extra">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?  </div><div class="gmail_extra">  <a href="http://clang-developers.42468.n3.nabble.com/RFC-Implementing-the-Swift-calling-convention-in-LLVM-and-Clang-td4050248.html">http://clang-developers.42468.n3.nabble.com/RFC-Implementing-the-Swift-calling-convention-in-LLVM-and-Clang-td4050248.html</a><br></div><div class="gmail_extra">  <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-June/101338.html">http://lists.llvm.org/pipermail/llvm-dev/2016-June/101338.html</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">(although maybe a WebAssembly target might be a better research topic.)</div></div>