[Vm-dev] Amazing ARM simulator experience

[Eliot Miranda]

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/7dba5362/attachment.htm