[Self-interest] future of the Self VM

[Nathan Summers]

On Sat, Jul 31, 2021, 10:42 PM Jecel Assumpcao Jr <jecel at merlintec.com>
wrote:

> 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?
>
> 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.


    - changing the C++ VM to handle 64 bits and target the currently
> popular processors
>


Part of the problem with the existing C++ VM is that it makes assumptions
about the address space that were true when it was written but aren't
today. Specifically, it assumes that each platform can set a #define for an
address that is guaranteed to have a large amount of free memory at it.
With the address space randomization that modern operating systems do, this
is literally impossible. Also, the highest bit is expected to be zero in
real addresses, which is no longer true, at least in 32 bit mode.

I was able to work around both of these issues in my cygwin port by setting
two compatibility flags and hacking in some code to find a big enough block
of memory if the default spot isn't suitable, but that's not a sustainable
course.

Using the lowest bit to distinguish between addresses and integers instead
of the highest would probably work for x86 but might conflict with its use
for distinguishing between ARM and Thumb mode on ARM machines. (The
second-lowest bit would probably work in that case.) At any rate that check
needs to be made configurable.

 Adding x86-64 to a compiler that
> already can generate x86 code is another reasonable project. Supporting
> the ARM64 would require a larger effort.
>

It might be worth looking into an LLVM-based backend for newer targets.

Rockwalrus

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20210802/a00fa05d/attachment.html>