[Self-interest] future of the Self VM

[David Ungar]

Thank you, Jecel. I've not had much time to follow up since, but I sure enjoyed the presentation and discussion! I loved how you remembered details I had forgotten!

I don't know what inverse Klein would be, since a Klein bottle has only one side, anyway. Maybe just Klein? ;-)

Sadly, I don't recall the details of Klein clearly, after maybe 30 years!

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.

- David

> On Jul 31, 2021, at 7:42 PM, Jecel Assumpcao Jr <jecel at merlintec.com> wrote:
> 
> Russell's talk this past Wednesday was really great! I liked the idea of
> starting of with a demo building a slide viewer to use for the rest of
> the talk.
> 
> One of the slides was about options for moving the VM forward. I
> remember at least some of the alternatives - please add any that I
> forgot.
> 
> I would mention that a very significant reason Self never became popular
> was that it didn't run on machines people had (a problem shared with
> nearly all the Unix clones that came before Linux). This was why many
> people wrote their own Self variations or Self inspired languages in the
> early days. I actually bought a Sun Ultra 5 machine in 1998 (the most
> money I have spent in my life so far) so I could continue to use Self
> after I moved away from the University. Just a few years later with Self
> running on PowerPC Macs and later x86 Macs and Linux machines people
> could finally try Self. Sadly, they didn't because of the silly idea
> that only things coming out right now are worth looking into. With
> everybody moving to x86-64 and now also Apple ARM we are back where we
> started! So how do we fix this?
> 
>    - changing the C++ VM to handle 64 bits and target the currently
> popular processors
> 
> During the talk I mentioned the lack of progress in the StrongTalk VM as
> an example of how hard this is because you need developers who both like
> C++ and Smalltalk/Self. I was a nice surprise to be contradicted by
> George Cox who said he is actually working on StrongTalk:
> 
> https://github.com/gjvc/strongtalk-2020
> 
> The move from 32 bits to 64 bits in Squeak happened twice (first at HP
> and then with Eliot Miranda). That wasn't an absurd amount of work and
> even though there was some advantages in using Slang instead of C++ it
> is likely to be doable for the Self VM. Adding x86-64 to a compiler that
> already can generate x86 code is another reasonable project. Supporting
> the ARM64 would require a larger effort.
> 
>    - do a Graal/Truffle implementation
> 
> While I have no more interest in programming in Java than in C++, this
> is actually an interesting option. The TruffleSqueak project had nice
> results for (I might be wrong) a student-level effort. And with their
> Polyglot project the various languages can work together in a very nice
> way.
> 
> I think partial evaluation will be an important technology in future
> compiling VMs, but I don't know enough about Graal to evaluate this
> alternative.
> 
>    - patch OpenSmalltalk VM (Cog) used for NewSpeak, Squeak, Pharo and
> Cuis to support Self
> 
> This is something that I strongly recommended to the Slate guys even
> before Cog. I showed how a little tweak would allow multiple dispatch to
> be added to the VM. Many things needed to support prototypes (maps
> instead of classes, for example) don't actually make a difference at the
> VM level and so would require no changes. The way closures are handled
> in Cog and in the Self 4.1 bytecodes (previous Selves used message
> passing instead) are very different and Self needs to distinguish
> between implicit self sends and sends to "self". Resends a slightly more
> tricky than super.
> 
> Recently Cog has implemented support for multiple bytecode sets in the
> same image in order to support Sista. Note that Cog itself is a dynamic
> compilation system and it is the addition of Sista that makes it an
> adaptive compiler more comparable to the Self VM. While there is VM
> support for Sista in the form of an alternative bytecode set it mostly
> exists in the image and so wouldn't help a Self system running on Cog.
> 
>    - Klein
> 
> The OOPSLA 2005 paper on Klein (available to ACM members) include the
> video fo the talk by David Ungar, Alex Ausch and Adam Spitz (available
> to everyone):
> 
> https://dl.acm.org/doi/10.1145/1094855.1094865
> 
> One interesting thing in the talk was showing both Klein running inside
> Self (like the Squeak Simulator) as well as running on a separate
> computer (making it a SqueakNOS). I think it is a very interesting
> project that could be extended in worthwhile directions (like running on
> top of an operating system for those who like that sort of thing and
> handling multiple processors like the RoarVM).
> 
> My first impression when trying to browse through Klein code was of some
> confusion. I soon found out that many of the methods I was looking at
> had been generated and that I needed to look at the sources for them
> instead. Is this actually the case? It was a while ago so I might be
> remembering it wrong.
> 
>    - inverse Klein
> 
> I have no idea what this means.
> 
> -- Jecel
> _______________________________________________
> Self-interest mailing list
> Self-interest at lists.selflanguage.org
> http://lists.selflanguage.org/mailman/listinfo/self-interest