[Self-interest] future of the Self VM

[David Ungar]

I love the thinking going on!

BTW, the old Mac port that still runs on Mojave uses Quartz for UI2. UI1, though, still uses X.
I just got another machine, a 12-in MacBook running it today. A slow machine by current standards, but fast for Self!

- David

> On Aug 2, 2021, at 8:48 AM, Nathan Summers <rockwalrus at gmail.com> wrote:
> 
> On Sat, Jul 31, 2021, 10:42 PM Jecel Assumpcao Jr <jecel at merlintec.com <mailto: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
> _______________________________________________
> Self-interest mailing list
> Self-interest at lists.selflanguage.org
> http://lists.selflanguage.org/mailman/listinfo/self-interest

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