http://bugs.winehq.org/show_bug.cgi?id=30134 --- Comment #10 from Anastasius Focht <focht(a)gmx.net> 2012-04-12 18:44:54 CDT --- Hello André, --- quote --- small step --- quote --- for man ... one giant leap for mankind ;-) Not sure if it's worth to pursue full Thumb1 compatibility for all "generated" code passed to assembler. Everything else will be Thumb2 anyway when built with modern toolchains using Cortex-A profiles.
From what I've read, native Windows-on-ARM apps/code will make use of Thumb2 instruction set which actually makes sense if you look at the required minimum specs for Windows on ARM (ARMv7 and above). Not taking advantage of the instruction set just wastes lots of potential (code density).
Some links: http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-p... http://www.bitcrazed.com/post/2011/09/20/Visual-Studio-11-Developer-Preview-... (disassembly screenshot indicates Thumb2). --- quote --- i played a bit with: case CPU_ARM: output( "\tldr r0,[pc,#0]\n" ); output( "\tmov pc, r0\n" ); output( "\t.long 1f\n" ); and forcing "as" to -mthumb (that code can be compiled to arm and thumb) without good results... maybe you can debug that further... --- quote --- You need something that gets it right for ARM, "old" Thumb1 and Thumb2 without mode switching. You could make use of "ADR" pseudo instruction. Something like this might work: --- snip --- adr r0, 2f ldr r0, [r0] mov pc, r0 .align 2: .long 1f __wine_spec_pe_header: .skip xxx 1: ... --- snip --- Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.