[Vm-dev] Bochs simulator plug-in structure

[Igor Stasenko]

On 12 May 2012 11:09, Lars <lars.wassermann at googlemail.com> wrote:
>
> Hi all,
>
> I am Lars, one of this years GSoC students, and my project is implementing
> an ARM Simulator plugin and subsequently an ARM JIT for the Cog VM[1].
>
> Last week, I had a meeting with my mentors, Eliot and Stefan, and I will try
> to summarize my understanding of the Cog VM structure here. The main topic
> of our chat was the overall structure of the project and a timeline, and the
> functions of the Bochs simulator for the CogVM x86 JIT. This summary is
> based on our protocols and my understanding and might not be correct.
>
> The Bochs x86 simulator[2] is a CogVM plugin writen in C to interface with
> the Bochs x86-64 C++ simulator[3]. The Bochs simulator can emulate an Intel
> x86 CPU and i.a. common I/O devices, a BIOS, and different instruction
> extensions like MMX. Of all that, only disassembling, single and multiple
> instruction execution and error decoding is used.
> The Bochs plugin keeps track of the ByteArray into which code has been
> compiled. It has to do so, because the Smalltalk VM garbage collector may
> move it around in memory. The plugin implements several (5?) primitives,
> which are:
>
> single instruction execution on given memory in form of a ByteArray;
> using the Bochs' disassembler, in order to compare the supposed meaning of
> some bytes from a ByteArray with its interpretation by an emulated CPU;
> execution of code from the byte array until an interrupt or error. Note that
> the CogVM uses a heartbeat (~once a second?) (for GC?) which is an interrupt
> and thus the simulator will not run longer than between two heartbeats;
> accessing the error codes which are provided by the Bochs;
> accessing the register state of the simulated CPU?
>
> The ByteArray to provide for the simulator contains an image: Objects, a
> Stack, and Instructions. But whenever the Bochs code comes to instructions
> where it would have to interpret Smalltalk code, the instructions are
> generated in such a way, that it accesses an illegal memory address and thus
> stops, back to the Smalltalk VM, which then interprets the Smalltalk Code
> and afterwards continues the simulation.
> So the plugin also maintains these false addresses.
>
> The simulator is used to have stepwise debugging and automated tests before
> coping with a real CPU, where debugging would be much more tedious.
>
> There has not been a definitive decision on which ARM simulator to use, but
> according to a previous try[mail was directly to Eliot], most open source
> ARM simulators are not worth using. I.a., QEMU is not viable[4]. So far, a
> good choice seems to be the GNU ARMulator[5]. Another one mentioned in our
> chat was SkyEye[6].
>
> In order to use/test the simulator, an ARM compiler is needed. The CogVM
> includes an abstract instruction set as one of two basic intermediate
> languages. These instruction are for an abstract 2 register machine (because
> x86 is a 2 register machine) and are implemented in subclasses of
> CogAbstractInstruction for actual IAs. Instances of CogAbstractInstruction
> are single instructions for that abstract machine. The x86 subclass is
> CogIA32Instructions. ARM actually is a 3 register machine.
>
> Those abstract instruction objects are created by an instance of the Cogit
> and should provide assembler which then populates a ByteArray.
>
> This was an abstract overview of some two key parts which are needed for
> JITting. We meet again next week and Eliot plans to show me around the code,
> which implements the above described functionalities.
>
> At the moment, my semester is still running, so there might not be much
> progress. But in the beginning of June, most of the lectures will be done.
> All the best,
> Lars
>
> [1] http://gsoc2012.esug.org/projects/arm-jitter
> [2]
> http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/
> [3] http://bochs.sourceforge.net/
> [4]
> http://lists.squeakfoundation.org/pipermail/vm-dev/2012-March/010210.html
> [5] http://en.wikipedia.org/wiki/ARMulator
> [6] http://sourceforge.net/projects/skyeye/?source=directory

Reading [4]. I think best option is to implement simulator in Smalltalk.
Yes it may be slow. But you spend much less time implementing it, and
when it will be done and working,
then you can port it to C/C++, or generate x86 code for simulating
given ARM instructions and
run them using NativeBoost.

-- 
Best regards,
Igor Stasenko.