<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<p>
<blockquote type="cite">Hunh - I didn't remember that at all; I
thought Boris Shingarov had been Mr OS/2-Squeak.</blockquote>
There were two OS/2 ports that did non-overlapping things because
they were designed with orthogonal goals in mind.</p>
<p>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.</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>
<blockquote type="cite">I wouldn't be surprised if it still works.
But this was never part of the official releases.</blockquote>
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.<br>
</p>
<p><br>
</p>
<p>
<blockquote type="cite">
<p>Later this was the base of his extremely interesting Cheese
project.</p>
</blockquote>
Oh yes -- Cheese. This is what 3 years later led to the work on
Eclipse SWT.<br>
</p>
<br>
<p>
<blockquote type="cite"><i>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.</i></blockquote>
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.</p>
<p>Where does this stand right now?</p>
<p>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.</p>
<p><br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p><br>
</p>
<p>So.<br>
</p>
<p>Is there an environment where work would not be blocked by such
problems?</p>
<p>Let's look.<br>
</p>
<p>
<blockquote type="cite">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<br>
correctly. So in their repository and workflow, it really is a
source fork.</blockquote>
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 <b><i>headless</i></b> branch, but it
doesn't even compile in Pharo. I tried asking on pharo-dev, but I
got zero responses since February.</p>
<p><br>
</p>
<p>So.</p>
<p>The million-dollar question again:</p>
<p>Is there *any* environment that works well enough to do OST VM
work in?<br>
</p>
<blockquote type="cite">
<p>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.</p>
<p>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.</p>
<p>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 :-)</p>
</blockquote>
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.<br>
<p>-- boris<br>
</p>
<p><br>
</p>
</body>
</html>