Skimming through the information available on the Cortex A9 I have noticed that there are quite a bit of peculiarities in the design. Here's a quick run-down to fuel discussion:

- Out-of-order completion is mentioned though there is very little information about it. The only other mention I found was that an instructions 'releases the resources it is consuming early'. Maybe it means that an instruction can write-back its result and free the renamed register before completion if it safe to do so?

- It seems that the LSU is skewed as they mention a single-cycle load-to-use penalty (same as on the Cortex A8). A hardware prefetcher is also mentioned but there is no information about it.

- Some sort of load-store forwarding mechanism is mentioned in the white paper though it is not described how it works or what it does exactly. Maybe back-to-back load/store couples have a lower latency because the data is allowed to bypass some stages and go directly to the store queue?

- The L1s in Cortex A8 were PIPT, I believe this still holds true for the A9. This means that the TLB must be fairly small, a potentially significant disadvantage in more desktop-oriented workloads. I wonder if there is a second-level TLB in there.

- When configured with an L2 cache, the L2 is exclusive (yay for K7!), certainly a good thing for the smaller incarnations of the A9.

- The A9 has fast loop mode for lower-power operation but in the diagrams available it is depicted as being before the decode stage. This is similar to Conroe/Penryn cores which is strange because it comes after the pre-decode stage, something that the A9 shouldn't have. I would have expected it after the decode stage (like on Nehalem) so I was wondering if its sole purpose is to shut off the L1 I-cache for power savings.

- Finally it seems that they put a lot of effort into making I/O operations as well as thread-related operations very fast. The ACP for example is absolutely brilliant: on current consoles it is normal practice to lock part of the L2 to and write the GPU command buffer into it, then send it over using DMA to save an unnecessary read-write-read copy. Having this done transparently is simply excellent. It seems to me that they've done quite some work to make operations which usually disrupt an OoOE actually run very fast (peripheral I/O, TLS access and cache-to-cache transfers). On this topic I'd like to know more about the GIQ too because interrupt handling is an area which is often underestimated from a performance POV.