[Self-interest] future of the Self VM

Tue Aug 3 04:30:32 UTC 2021

Throughout the 2020-2021 academic year, I was actually working on a Self 
JIT compiler in C++ based off LLVM for a senior capstone project. Due to 
some drastic team-related incidents, I was only able to implement a 
(very) small subset, but, now that I know a lot more about interpreters, 
VMs, and JIT compilers, I am currently building a new implementation in 
Rust. I am planning to do a bytecode interpreter with the end goal of 
building a JIT compiler on top of that.

A lot of life changes going on post-graduation that are taking up a good 
chunk of my time, so I don't have a lot of time to spend on it 
currently, but it is one of my primary ongoing projects. Once I get 
something non-trivial, I plan on pushing it to a public GitHub 
repository. I would definitely welcome any input and feedback.

-- Nicklas Carpenter

On 8/2/2021 8:30 PM, Jecel Assumpcao Jr wrote:
> This is a great discussion. I will make all my comments here instead of
> in separate emails.
>
> Right after I posted my original email I saw that I was wrong about
> having to patch Cog to run Self. The difference between "selfSend x" and
> "push self; send x" was important in Self 1 for two reasons: private
> slots were ignored by the latter and the first allowed access to
> temporary variables and arguments. But private slots became a user
> interface only thing in Self 3 and local variables got their own
> bytecodes in Self 4.1. So Smalltalk bytecodes are good enough though it
> is a little awkward to handle resends.
>
> The 1982 paper "Multiple Inheritance in Smalltalk-80" by Alan Borning
> and Dan Ingalls uses the normal VM and their tricks would also work for
> Self-on-Cog:
>
> https://www.aaai.org/Papers/AAAI/1982/AAAI82-056.pdf
>
> Another alternative would be to run Self in Javascript, like SqueakJS.
> Note that on my machines and browsers SqueakJS is not as usable as it
> seems to be for other people unless I use really old images (like mini
> Squeak 2.2), but it does have many advantages. And my impression is that
> the Javascript object model is more similar to Self's than to
> Smalltalk's so the adaptation layer might be simpler.
>
> Russell Allen:
>> "Inverse Klein" idea: compile code to vector and run it
> In Squeak there was the Exupery project by Bryce Kampjes that did just
> that.
>
> http://www.squeaksource.com/Exupery.html
>
> Guillermo Adrián Molina used this technology to implement a complete
> Smalltalk called Huemul.
>
> https://dl.acm.org/doi/10.1007/978-3-540-89275-5_4
>
> https://www.guillermomolina.com/en/18-castellano/proyectos/huemul-smalltalk
>
> Igor Stasenko created the NativeBoost project for Squeak/Pharo which
> allows you to extend a method with native machine code and call that.
>
> http://www.squeaksource.com/NativeBoost.html
>
> Randy Smith:
>> Was this recorded? Would love to see it even post facto.
> The previous UK Smalltalker's talks have been posted to:
>
> https://vimeo.com/ukstug
>
> They take a little while to edit and post them, but we will certainly
> send a link to the video here as soon as it is available.
>
> David Ungar:
>> These days, I have gained a lot of respect for compiler support for immutability, and
>> have been doing so much Swift programming, I might be tempted to see how tough
>> a Self VM would be in that language. Just one more thing to throw into the stew of
>> possibilities.
> About constants, this is how I explain the advantages of adaptive
> compilation. Whether something is immutable or not depends on the
> timeframe we are talking about. Over decades nearly everything changes
> while in a single clock cycle the whole memory of a Von Neumann computer
> is constant except for a single word. So an ahead of time compiler will
> have to treat as variable things that an adaptive compiler can treat as
> immutable (with possibly the overhead of a check and recompilation if it
> ends up changing).
>
> Mario Wolczko:
>> I feel duty-bound to have a go at making a Truffle implementation.
> An AST-based Self would be pretty good, but I thought that bytecode
> support had been added as part of the TruffleSqueak project? Anyway,
> this was a great set of ideas!
>
> Slava Pestov:
>> bytecode interpreter?
> The changes from the Self 4.0 to 4.1 bytecodes was meant to make an
> interpreter more practical.
>
> In 1997 I did a Self-in-Self implementation called tinySelf 1 (not to be
> confused with tinySelf 0 which was a C program that parsed Self 3
> sources but didn't do anything with them) and it was a bytecode
> interpreter. It didn't implement primitives nor the memory system since
> it used the underlying Self for those. The big deal was that each object
> had its own thread, so it had a message queue and executed one message
> at a time. That meant that any recursion would deadlock and this was an
> experiment to work around that.
>
> http://www.merlintec.com/lsi/tiny.html
>
> This was implemented in one afternoon, but I made two huge mistakes. The
> first is that I implemented tail call optimization to allow more
> parallelism but should have left this for a second version as it
> eliminated information I needed to debug stuff. The second was that I
> used many off the shelf Self objects like lists as dumb data structures,
> so when I got bugs I couldn't patch them to find out where things were
> going wrong because the whole system used them and would break if I made
> changes.
>
> Steve Dekorte:
>> If a JIT is unnecessary, could WASM or JS be an implementation option?
>> If so, it seems this would effectively allow everyone to use it regardless
>> of platform via a single code base and target platform (the web browser).
> This would be a bit like the SelfJS option I mentioned above. My
> impression is that WASM is still evolving and so this might be more
> practical with future versions than the current one (implementing a
> garbage colletor, for example).
>
> Nathan Summers:
>> A big issue is that there isn't a Windows port that supports the native
>> windowing system. I was working on a port to SDL (which would double-duty
>> for Windows and Android) when the machine I was using broke.
> That sounds like a good idea. I think that the Mac version of Self uses
> a library that is no longer supported, so SDL might be good for that as
> well.
>
> When I was on the Squeak Oversight Board my job was to investigate ways
> to improve the graphics. At the time the only reasonable options that
> ran on the platforms we were interested in was embedded OpenGL, but that
> is no longer true (things got worse with Apple moving to Metal).
>
> -- Jecel
> _______________________________________________
> Self-interest mailing list
> Self-interest at lists.selflanguage.org
> http://lists.selflanguage.org/mailman/listinfo/self-interest