[SqNOS] Idea about changing the way we compile the VM

[Jecel Assumpcao Jr.]

Javier,

> Last night I had a really interesting idea about the VM...
> For now, we have a special VM platform that is "squeakNOS". This is sometimes
> a problem, we need a custom makefile, the VM gets old and we are still working
> with the old interpreter because of this. Supporting the makefile is really boring.

What are the Vm changes that we need? I thought it was just one plugin
to allow low level i/o and memory access plus a patch to find the image
pre-loaded into memory, right?

> What I'm thinking about, then? We have nativeboost to execute binary code, an
> assembler and even prototype of smalltalk to binary translator (waterfall),

I am not familiar with waterfall, but in the past we had a Smalltalk to
x86 translator in the Exupery project.

> wouldn't it be possible to use all that to make the standard unix VM work with the
> sq/NOS image?

The nativeboost and related parts would indeed be an alternative to the
plugin. But it seems to me that the startup patch to the Unix VM would
still be needed. I am sure it would be relatively easy to write code
that could work either way (in fact, isn't that already the case for the
SqueakNOS VM?).

> What work I think that would be required?
> - Making the image partly POSIX compliant? This means it should be able to receive
> syscalls and respond to them, probably doing nothing in most cases.

The image would be receiving syscalls from where? I think I
misunderstood this part.

> - Re-coding the support code written in C. But doing it in smalltalk and nativizing it
> with waterfall or with asmjit. This code is really short, shouldn't be much work.

And some of this support code isn't really in C anyway, since that
language has no notion of i/o ports. It would be interesting to have
multiple versions of such code in the same image if we want it to be
able to run on ARM computers as well as PCs at some point.

> - Moving some fancy stuff from actual Makefile to Smalltalk. The actual Makefile has
> to do some special linking of binary code. For example, it takes some binary code
> from libc and puts it in the VM. We'll have to do this from the image.

It seems that the current VMMaker tools are using CMake. If the goal is
to merge the SqueakNOS and Unix VMs, doesn't it make sense to use the
same things for both?
 
> What we gain? Important and cool stuff:
> - We don't need a special vm any more. This removes a barrier to entering the
> project.- We get this support code written in smalltalk so we get closer to the
> idea of a full-smalltalk OS- We get POSIX compatibility, this means we might be
> able to/get closer to execute code compiled for unix.- We get POSIX documented
> in smalltalk code... I don't know if somebody is interested in this anyway

Does the "execute code compiled for unix" part mean you want to run
stuff written in C within the image and have SqueakNOS pretend to be
Unix for that code? This seems like a completely different project from
having a single VM binary run on top of Unix and on bare computers. And
it is not something that would be very secure unless that code runs in a
separate address space.

By the way, in 1987 my then partner asked me if "it is possible to write
a Unix in Smalltalk". Though in theory the answer is "yes" (you can
always simulate some computer in Smalltalk and run Unix on that - it
would just be really, really slow) I replied "no", which resulted in a
series of events which killed our company. So I have given this question
a lot of thought in the past few decades....

-- Jecel