[Vm-dev] Amazing ARM simulator experience

[Ryan Macnak]

I'll second that simulators are an essential tool for building a JIT. In
the Dart VM, we have our own simulators for ARM, ARM64 and MIPS that allow
us to test changes against all the architectures we support, locally on our
x64 workstations. When we first got the VM running on iOS, we were even
running the ARM simulator on the iPhone to work around the
no-JITing-unless-you're-Apple policy (we have since completed an AOT mode).
Although it was sluggish compared to its JIT counterpart running on
Android, it was certainly usable. And given our loading code is also
implemented in Dart, having simulators allows us to cross-compile AOT code
for Android and iOS from x64 desktops.



On Wed, Jun 1, 2016 at 6:21 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Dimitris,
>
> On Wed, Jun 1, 2016 at 3:07 PM, Dimitris Chloupis <kilon.alios at gmail.com>
> wrote:
>
>>
>> My first computer that my father bought me in 1988 was an Amstrad CPC
>> 6128 , with a 4 Mhz CPU and 128kb Ram
>>
>> My latest computer is a late 2013 quad core 3 Ghz iMac with 8 gb memory.
>> Which makes it at least 3000 times faster than my Amstrad , technology has
>> come a long way the past 30 years. I could not imagine this future even in
>> my wildest dreams.
>>
>> By Gdb you mean the GNU debugger ?
>>
>
> Yes.  Gdb comes with a lot of different simulators.  So far for executing
> machine code in Cog we've used Bochs for x86 and x86_64, Gdb for ARM v6 and
> hand-written Smalltalk for MIPSEL.
>
>
>>
>> On Wed, Jun 1, 2016 at 8:43 PM Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>>
>>>
>>> Hi All,
>>>
>>>     just had to tell people about this morning's experience using the
>>> ARM simulator.  I've been building Smalltalk VMs since 1983, so 33 years.
>>> My first on the Three Rivers PERQ was dog slow.  My undergraduate project
>>> was done the the National Semiconductor 32016 based Whitechapel Computer
>>> Works workstation and its and 32032-based successor.
>>>
>>> This morning I was revamping register management in Cog's ARMv5/v6 back
>>> end, making more registers available by using two of the C argument
>>> registers for two of registers the Cogit assigns to various fixed tasks,
>>> and using store and load multiple instructions to save and restore
>>> concisely the registers around calls into the runtime.
>>>
>>> Remember the architecture here.  The simulator generates ARM machine
>>> code into the ByteArray that re[resents the address space, holding all of
>>> generated machine code, a small C stack, and the Smalltalk heap.  A plugin,
>>> derived from Gdb's ARM simulator written in C, interprets that machine
>>> code, running for a couple of milliseconds at a time in a loop, applying
>>> breakpoint calculations, and asserts on every call into the run-time, and
>>> that calls into the run-time and accesses of variables in the simulator is
>>> done by using illegal addresses in the generated machine code.  Each
>>> illegal access causes the Gdb-derived machine code interpreter to return
>>> with an error, this error is turned into an exception, the handler for
>>> which maps the specific illegal address into a variable or message
>>> selector, accesses the variable or activates the message selector,
>>> providing the result, and allowing the execution to continue.
>>>
>>> In changing the register management I had a test case that worked, an
>>> image that prompted for an expression ands evaluated it, which worked both
>>> in the simulator and with the generated VM.  But the real VM, crashed when
>>> used on a proper image.  So to debug I started launching the real
>>> interactive image in the simulator.
>>>
>>> Well, the amazing experience is that that image, whose machine code is
>>> being _interpreted by a C program_ feels /faster/ than my 32016 based
>>> implementation back in 1984-ish.  Quite amazing.  I can open windows, type
>>> text, access source code (was playing with Message Names) etc.  It's
>>> sluggish, but usable.  Amazing how fast modern machines are.  All on my
>>> 2012 vintage 2.2 Ghz Core i7 MacBook Pro.  I'm blown away :-)
>>>
>>> _,,,^..^,,,_
>>> best, Eliot
>>>
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/d0eb5ac0/attachment-0001.htm