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

[David T. Lewis]

Hi Boris,

Replying with CC to the Squeak oversight board - we have a meeting scheduled
tomorrow, and I would like to put the following topic on our agenda. Let's
see if we can to something to help. From Boris Shingarov's message:

    
    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.

I will not even pretend to understand some of the issues being discussed,
but things like SUnit problems and availabity of JSON (for example) are
surely things that we can make progress on.
    
Dave



On Tue, May 19, 2020 at 01:05:53PM -0400, Boris Shingarov wrote:
>  
> 
> >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
> 
>