processor emulation

 
I just found out about this project:

https://github.com/guillep/pharo-unicorn

It seems to offer similar functionality as Bochs but can simulate other
processors such as ARM or MIPS. Could this be an alternative for Cog?

-- Jecel

 

 
Eliot,

> This looks much more like Pharo trying to strike out on its own.

I was talking more about the Unicorn project itself, which borrows code
from Qemu but as a usable library for just the CPU. I noticed Pharo in
the list of languages with Unicorn bindings and found the link with an
example of what it would look like in Smalltalk.

The issue is that now we have 3 very different solutions for x86, ARM
and MIPS. So I was wondering if a single solution wouldn't be better?

-- Jecel

 

 
Hi Jecel,

Well given that two of the solutions work fine and that Boris Shingarov is investigating using the Gem5 simulators, trying to unify has no point.  It’s just work.  But if it excites you, go for it.  I don’t have spare cycles :-)

>
> -- Jecel

 
Eliot

> Well given that two of the solutions work fine and
> that Boris Shingarov is investigating using the Gem5
> simulators, trying to unify has no point.

Gem5 would indeed be a better solution given that we don't need real
time emulation for debugging the compilers. I had forgotten about that
project in this context.

>  It?s just work.  But if it excites you, go for it.  I don?t
> have spare cycles :-)

I am going in a slightly different direction.

-- Jecel

 

>  
>
> Well given that two of the solutions work fine and that Boris Shingarov is investigating using the Gem5 simulators, trying to unify has no point.  It’s just work.  But if it excites you, go for it.  I don’t have spare cycles :-)

Alright, now that my name got mentioned in this discussion, I'll chime
in to explain where we are with that project.

The idea is to use the widely-adopted GDB interfaces to drive the
debugging of the VM on a wide range of targets, so that the difference
between Simulation and Production mode is erased. Indeed I have booted
up Cog interchangeably on purely-software-emulated CPU, on hard-silicon,
and on FPGA, completely transparently to Cog and the VMSimulator.

More interestingly, the Smalltalk API to the underlying GDB is designed
to admit also other backends, such as the Angr symbolic execution
engine.  This will server as the basis of Cog's formal verification
(although I have not yet booted full Cog symbolically, only small
fragments).

What works today?  We have been running simulations of existing i386 and
ARM Cog both on gem5 and on off-the-shelf hardware for several months,
both in Squeak and Pharo host images (the code for both environments is
publicly available).

The all-new PowerPC backend successfully boots to the Reader prompt. 
The code is available at

https://github.com/shingarov/opensmalltalk-vm

https://github.com/shingarov/SmallRSP

https://github.com/shingarov/Pharo-ArchC

https://github.com/shingarov/MachineArithmetic

Setting it up is highly nontrivial, but not a
"kids-please-don't-try-this-at-home" kind of deal.  On the contrary, I
invite everyone interested and I am willing to show you how to run it.

This is obviously a very long way from being usable for actual Smalltalk
app development by customers; if there is interest, we can talk about
what the next steps need to be.