Porting my x86 emulation core to Windows Phone 8

via http://ax86.patrickaalto.com/ablog.html


For the past couple of weeks I have been porting my x86 emulation core to run on Windows Phone 8 platform. This has not been quite as trivial as I would have hoped. There have been many changes I have needed to do to get my ASM code (all 85.000 code lines of it!) to compile for Windows Phone 8. Here is a list of the major differences and the fixes I have needed to do:

• Windows Phone 8 does not allow you to run ARM ASM code! For some peculiar reason it forces you to use only Thumb ASM code. Luckily the new Thumb2 (available on ARMv7 processors) ASM code is much improved compared to the original Thumb ASM format on the ARMv5 processor (as in a Nintendo DS, for example). It allows you to specify when an arithmetic operation should change the processor flags, and has pretty much all the same features as the ARM version. It has some limitations, though, like not allowing you to set the processor flags using a literal value instead of a register, etc.
• Microsoft uses the ARMASM ARM Macro Assembler, which of course has quite different syntax (compared to the GNU assembler I use elsewhere) for compiler directives and especially macros. This has been the most time-consuming problem, as I use a ton of assembler macros in my emulation core and have had to rewrite all of them. Luckily at least the Microsoft ARMASM macros have similar features to the GNU assembler, so I have not had to make other changes besides the syntax. The bad thing was that I had been lazy when calling the macros and had not used commas between the macro parameters (which is not required by the GNU assembler, but is required by ARMASM). So I had to change also all macro calls where the macros use more than one parameter.
• My code is based on a lot of jump tables, and this generates a new problem in Thumb code. In my ARM code I have all the jump tables inside the code section, immediately following the code that needs to use the jump table. However, there is a (withdrawn) ARM document that describes the problem of defining data inside a code section: The linker automatically adds 1 to all addresses in the code section (thus making the data address unaligned), as it assumes the address is a jump target (where the lowest bit set means this is a jump target in Thumb code). This withdrawn document describes that I could use a DATA directive to tell the assembler that my jump tables are actually data, but this does not work in the Microsoft ARMASM, at least. A newer ARM document states that the DATA directive is obsolete and is ignored, but there does not seem to be an alternate way to make the data-in-code addresses aligned. So, I have had to move all my jump tables to the data section, and load their addresses separately whenever I need to use the jump table, thus slowing down the code somewhat.
• Local label search order differs between GNU ASM ands ARMASM. Gnu assembler looks for local labels (like b 1) forward unless you use the b letter (like in b 1b), while ARMASM looks for the closest label backward unless you use the f letter (like b %f1). I had not noticed this difference untill running the unit tests, and the first opcode that had a forward jump (where I used bcs %1) crashed, as it jumped backwards to some completely different code.