[Vm-dev] Simulating trunk6.image in Spur64VMMaker

David T. Lewis lewis at mail.msen.com
Wed Feb 12 13:26:29 UTC 2020


On Tue, Feb 11, 2020 at 12:12:08AM -0800, Eliot Miranda wrote:
>  
> Hi Subbu,
> 
> > On Feb 10, 2020, at 11:45 PM, K K Subbu <kksubbu.ml at gmail.com> wrote:
> > 
> > ???On 10/02/20 8:59 PM, Eliot Miranda wrote:
> >> If you want to develop specific primitives, optimizations, etc, that are invoked from specific Smalltalk expressions you'll find simulating the "reader" image, which contains a Real-Eval-Print Loop (a REPL), much easier than trying to interact with the desktop through the world menu.
> > 
> > Thank you very much for your quick and detailed response. I created a swiki:
> > 
> > http://wiki.squeak.org/squeak/6640
> > http://wiki.squeak.org/squeak/79 (updated)
> > 
> >> It is also perfectly repeatable.  Another approach is to save the image using a doit and have that doit include, after the snapshot, the code you want to run.  Another technique that saves time is to save the image containing the simulator with an open simulator having reached some point, such as the start of a garbage collection. You can then rerun the code you're interested in my reloading the image and continuing the simulator.
> > 
> > I saw Clement's excellent video at https://youtu.be/hctMBGAXVSs and his blog https://clementbera.wordpress.com/2016/05/30/simulating-the-cog-vm/
> > 
> >>    What are the options if I want to open V3 images in this simulator?
> >> Just change  ObjectMemory Spur32BitMemoryManager to ObjectMemory NewObjectMemory
> > 
> > I could'nt get the simulator to open 6502/6504 images. I got 'incomaptible image format' error [sic]. When I tried with ObjectMemory, I got a MNU on coInterpreter in initialize.
> 
> IIRC Cog only runs 6505 images.  There???s the closure bytecode set constraint and floating point order constraint.  And ObjectMemory won???t work.  If must be NewObjectMemory.

Cog can run 6505 images in addition to 6504 (but it cannot run 6502).
The only real difference between 6504 and 6505 is the word ordering
of Float objects, which gets resolved in the process of loading the
image.

I don't know if it matters, but if you want to run a 6504 image
in the simulator it would probably be a good idea to first run
that image on Cog and save it, such that the image is stored
as 6505.

> 
> A useful but difficult task would be to merge David???s VMMaker Context interpreter into Andreas??? much improved Context interpreter that he did at Qwaq, that was my starting point for Cog (& is the Context interpreter in VMMaker.oscog).  Amongst his improvements were the profiling improvements that support AndresProfiler.
>

Indeed the AndreasProfiler support is an important missing thing in
the "interpreter VM" code base.

The ContextInterpreter in VMMaker "trunk" (as opposed to VMMaker.oscog
for Cog/Spur) is nothing more that a refactoring of Interpreter into
the stack interpreter and (original) context interpreter. Today it
contains the development work for "interpreter VM" since the oscog/trunk
fork.

At some point, I tried to incorporate Andreas' profiler work from
VMMaker.oscog into ContextInterpreter, but I was not successful in
getting it to work. It would still be an important and good thing
to do.

Dave
 


More information about the Vm-dev mailing list