[Vm-dev] Slang for Cuis (WIP, experimental)

[Boris Shingarov]

> Hunh - I didn't remember that at all; I thought Boris Shingarov had 
> been Mr OS/2-Squeak.
There were two OS/2 ports that did non-overlapping things because they 
were designed with orthogonal goals in mind.

Juan's port was a "real PresentationManager/2 application", but it was a 
real PM/2 *Squeak* in that it opened a PM/2 window and BitBlt'd the 
Squeak Display to that.

Opposite to that, the idea of "real PM/2" to me meant "Native Widgets" 
and I wanted to have that in Squeak.  The problem was, in a live system 
(which is also "truly single-threaded"), how do I debug the 
"native-widget" event loop when the PM/2 is tied up by the BitBlt UI?  
This meant that Juan's design wouldn't fit: I needed to somehow have all 
the Squeak tools but without touching PM/2.  This was enabled by two 
things: (1) compiling the VM with Ian's sqXWindow.c, so Squeak would 
show on an X display while appearing to OS/2 initially as a headless app 
talking to the network, and (2) writing an FFI for the VM -- 
"native-widget" PM/2 calls were made via that FFI.


> I wouldn't be surprised if it still works. But this was never part of 
> the official releases.
I very much wanted to merge it upstream into Ian's unix port (the diff 
was very small).  The desire seems weird and silly now, but back then I 
somehow thought it would make a difference, and I remember I was very 
frustrated that the merge didn't happen.  But it *is* part of the 1.23 
distribution on files.squeak.org today.


> Later this was the base of his extremely interesting Cheese project.
>
Oh yes -- Cheese.  This is what 3 years later led to the work on Eclipse 
SWT.


> /I started with dissecting Slang out of the Cuis VMMaker packages and 
> VMMakerJS (SqeakJS) project into a couple of packages which could be 
> used for generating anything besides VM plugins./
You don't need Alien plugins to do VMIL18-simulation-style development 
of the core VM.  For that there is now the Smalltalk implementation of 
RSP, which I recently added to VMMaker.  There is a wide choice how to 
run the native CPU code: various simulators (gem5 or qemu), or on 
production silicon under GDB, or on some FPGA prototype under OpenOCD, 
... well ... really anything that knows how to speak RSP.  This will 
have a number of far-reaching consequences; this margin is too narrow to 
explain them, but you can watch a number of my presentations on the subject.

Where does this stand right now?

VMIL-18-simulation of Cog runs fine over RSP.  VMMaker depends on a 
subtle inaccuracy in the Alien's emulation of instruction atomicity.  
This will cause VMMaker to fail on off-the-shelf production silicon.  
But when you modify the CPU to behave like Alien, OSTVM runs just fine 
(I verified on gem5).  So it's a matter of very small fix to the Cogit 
to match what the stock processor is doing, before we have the full 
freedom to run anywhere we want.


The larger problem that stops me from bringing in all the rest of the 
system (the target-agnostic synthesizer, the binutils-in-Smalltalk, the 
symbolic execution engine, the superoptimizer, etc), is the lack of a 
usable mother-Smalltalk.

OSTVM is hosted in Squeak.  With all my love for Squeak, I still can't 
use it for this kind of work.  There are blocker problems with SUnit 
(causes erratic behavior of Socket code which works fine outside SUnit), 
so I can't have tests, I resort to launching everything from doits.  I 
have no PetitParser.  I have no JSON.  I can't use my FFI-to-Z3 
bindings.  In the middle of working I randomly get unexpected problems 
with access to source.squeak.org.  And so on.


So.

Is there an environment where work would not be blocked by such problems?

Let's look.

> Pharo VM did not only fork the transpiled C code, they also put the 
> Smalltalk VMMaker code in the repository and maintain it there. They 
> do not use the VMMaker Monticello repository if I understand
> correctly. So in their repository and workflow, it really is a source 
> fork.
You must know some magic!  something I've been begging the Pharo people 
for months to tell me the secret where to download that source from.  I 
tried the */headless/* branch, but it doesn't even compile in Pharo.  I 
tried asking on pharo-dev, but I got zero responses since February.


So.

The million-dollar question again:

Is there *any* environment that works well enough to do OST VM work in?

> I started with dissecting Slang out of the Cuis VMMaker packages and 
> VMMakerJS (SqeakJS) project into a couple of packages which could be 
> used for generating anything besides VM plugins.
>
> Atleast that's my intentiont, I don't yet know of how that project 
> idea will pan out, atleast I intend to learn something of how Slang 
> works and how it's generated.
>
> It's currently highly expiremental, but I got some of the existing 
> VMMaker testscases "green" and so I thought I could share the current 
> state of it. Maybe the whole idea of using it outside the VMMaker is 
> not so a good idea, maybe, maybe not :-)
>
For the reasons I just explained above, I believe it would be more than 
just "a good idea".  It is critical to the viability of this whole 
stack.  If your project works, it give us an environment enabling 
further collaboration on OSTVM.  Well, I must admit I don't know which 
way is shorter / more straightforward: this, or making Squeak work.  I 
would be happy either way.  I don't care which: I have much bigger fish 
to fry.

-- boris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200519/fd9d1dc9/attachment.html>