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

[Ben Coman]

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.

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 :)