PhillipJ said:
Slightly bigger unless it's using "thumb" instructions which is unlikely as not all instructions are available in the thumb set.
[edit] Little comparison here, only three samples, the ARM binaries are 7% to 15% bigger than the x86 binaries.
http://www.brightsid...6.aspx?pageid=1
IMO that comparison is out of date. If code density matters this much to you on Cortex-A8 you can use Thumb-2, which has all of the functionality of ARM and nearly all of the per-instruction expressivity while still providing much smaller code size; binaries in Thumb-2 generally run nearly as fast (within a few %). Thumb-2 was mainly rolled out for deeply embedded platforms where code has to fit on a small amount of cache, like the Cortex-M series. But it's still an option on A8 and A9.
For the record, the other usual arguments presented in that link are kind of inaccurate and cliche... it's getting a little off topic but I can't really hold back:
Number one: a "CISC" instruction set isn't automatically more expressive than a "RISC" one. Compared to ARM, x86 is optimized in all the wrong ways, and ARM is in many ways more powerful per-instruction, except for memory operands which only works well for the x86 archs that support it well; which granted does include Atom.
Number two: converting to "RISC" micro-ops internally is a trick that only really helps OoE throughout, and that's why Intel's in-order superscalar CPUs like Pentium 1 and, more recently, Atom,
don't do this. Moreover, this still doesn't overcome the limitations of x86 which end up surfacing as a front-end bottleneck, which is actually relevant when decoding on x86 is so expensive. Especially for Atom which can "only" decode 8 bytes per cycle - on Cortex-A8 this is no different, but you're actually guaranteed to get two instructions out of that. If you use immediates greater than 1 byte or more modern instructions with lots of prefixes it'll quickly be easy to exhaust this. Without OoE and renaming the two-address instructions and limited register file hurt you more on Atom. Or at least his is the impression I get when hand scheduling ASM for it.
Number three: claiming that being an OoE CPU puts Cortex-A9 on footing with modern desktop x86 CPUs. Nope, those are still much wider. I've seen people claim that OoE increases performance 4x (and that's why Wii's CPU is actually stronger than XBox 360's and PS3's main PPC cores.. although clock for clock I'm sure it is much better)
Finally, hyperthreading can be good, but it's a double edged sword - on Atom having it on can actually hurt performance in single-threaded dominating situations because of increasing pressure on a starved BTB (Agner Fog has talked somewhat indepth on this).
!
