[Vm-dev] VM Maker: VMMaker.oscog-rmacnak.1595.mcz

[Eliot Miranda]

On Wed, Dec 16, 2015 at 1:00 AM, Ben Coman <btc at openinworld.com> wrote:

>
> On Wed, Dec 16, 2015 at 10:43 AM, Ryan Macnak <rmacnak at gmail.com> wrote:
> >
> > On Tue, Dec 15, 2015 at 10:50 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >>
> >>
> >> Hi Ryan,
> >>
> >> On Mon, Dec 14, 2015 at 7:32 PM, <commits at source.squeak.org> wrote:
> >>>
> >>>
> >>> Ryan Macnak uploaded a new version of VMMaker to project VM Maker:
> >>> http://source.squeak.org/VMMaker/VMMaker.oscog-rmacnak.1595.mcz
> >>>
> >>> ==================== Summary ====================
> >>>
> >>> Name: VMMaker.oscog-rmacnak.1595
> >>> Author: rmacnak
> >>> Time: 14 December 2015, 7:29:18.283 pm
> >>> UUID: 3aac3671-b1ff-45b9-8ed0-f3ecc5bca0b3
> >>> Ancestors: VMMaker.oscog-eem.1594
> >>>
> >>> MIPS: Complete simulation of the Newspeak test suite! (~30 billion
> instructions) (Modulo Aliens, which don't work under the IA32 simulation
> either.)
> >>
> >>
> >> Can you say a little bit more about this?  How long did the simulation
> take?  What machine(s) did you run it on?  I *love* that you caught the MNU
> in followForwardingPointersInScheduler. I want to set this up for Squeak
> but never had the patience/.resources before.
> >
> >
> > This was a Newspeak image setup to run the test suite at startup and
> display the results on the Transcript, running the normal VM simulation
> setup on my Mac. I think the process had ~19 hours of CPU time when it was
> finished, but this is an overestimate because the simulation stopped for
> each of those bugs in the last commit. The IA32 simulation is an order of
> magnitude faster, Bochs being written in C and my MIPS simulator being
> written in Smalltalk with gratuitous asserts. Of course the MIPS one is
> much easier to add a jump buffer to and get a limited form of back-in-time
> debugging...
> >
> > I don't think this process is well-suited to automatic testing. Both the
> VM simulator and the Squeak-based system it's running have too many
> assumptions that they are running interactively. In the simulator I had to
> disable prompts that trigger on code compaction, primitiveExecuteMethod,
> etc. The test harness being run had to be altered to report to the
> Transcript. And if an unhandled exception had occurred in the simulated
> image that simulator wouldn't have known to stop. This is tolerable as a
> one-off to bring a new backend up, but not a productive way to test that
> the system stays working.
> >
> > What would be more helpful is if the VM build was fixed to work with a
> cross compiler, so it would compile fast enough to test ARM and MIPS on
> Travis CI alongside IA32 and X64.
>
> As I recently reported, I successfully cross compiled a VM using
> CMakeVMMaker on pharo-vm from github, from Debian to (NetBSD based)
> RumpKernel.
>    https://github.com/pharo-project/pharo-vm
>
> I'll be wanting to do the same targeting ARM later on, per...
>    https://github.com/rumpkernel/wiki/wiki/Howto:-Cross-compiling
> and even cross-execute it...
>
> https://github.com/rumpkernel/wiki/wiki/Howto:-Cross-architecture-execution
>
> Except did I read somewhere that Cog doesn't run on top of QEMU?  I
> can't find the post I thought I saw describing why.
>
> Right now I'm having a go at cross compiling to RUmpkernel using...
>    http://www.mirandabanda.org/cogblog/compiling-the-vm/
>    svn co http://www.squeakvm.org/svn/squeak/branches/Cog oscogvm
> I've encountered a few things in the autoconf that are incompatible
> with cross compiling, which I'm trying to fix and will report soon.
>
> btw, what was the outcome of developing the CMake builds for the svn
> sources.
>

The person doing it dropped out of the conversation.  I fear I didn't give
him enough time or feedback.  They contributed input support for the
simulator which I'm now using, but it was some months after the
contribution that I was able to integrate it.

cheers -ben
>
>
> > It would also help if the top-of-tree Intel VMs were always kept working
> so we'd know which change broke something. Moving the Subversion repository
> to a more reliable host (which likely means migrating to Git) would also
> cut down on the false positives Travis reports because the Subversion
> server has a habit of dropping connections.
>
> +1 github :)
>



-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151216/2a84e772/attachment.htm