I will be very much interested to hear this. Some of the Cortex M devices are reaching this level of performance. If Intel comes down this far, and QFN/QFP packages are available, I could see this being a possible device that a hobbiest could use. I will be very interested to see more about this device.
I am particularly curious to see what packaging options this device will come in. I am wondering if this product is aimed at the Cortex M market, or the lower end of the Cortex A series? If it is aimed at the M, say M4F with a higher clock speed, it would be interesting to see this type of device in a QFN and QFP. If it is competing with the A series, I expect that this will only be available as a BGA.
I don't know anything, except that AMD64 introduced a lot more than just a bigger address space. IA32 is really not a good/modern ISA, and it would be quite strange to see Intel falling back 10+ years. one real register, stack-based x87, no vectorization, etc. at the time, 64b extensions were justified as not adding a lot of chip complexity - of course that's relative to OoO/superscalar stuff.
At the core level most stacks are the same but the McAfee stack in recent years is probably one of the most comprehensive in terms of publicly listed features. I build my own stacks (like a secure android variant we are building right now) so do not end up doing detailed competitive analysis.
But no publicly available stack has a cohesive published security architecture. Makes me nervous since I cannot do a vulnerability analysis ! literature tends to focus on bells and whistles.
But all f this is missing the wood for the trees. Security engineering is an exercise in futility unless you have a proper trust chain starting with secure boot. You need cryptographically secured boot loaders and kernels for starters. At least for systems used in critical infrastructure.
On top of the hw you need an os designed for this millennia, not the various variants we have that derive their inspiration from the 70s. curiously enough the MS kernel internals is not half bad since it was conceived in the 80s. For believable os level security you need capability based os, better isolation thru micro kernel like techniques, tagged instruction sets (see crash-safe.org), mandatory use of signed code and so on and on.
Stacks come on top of this.
It is a pity that in the era of abundant cpu cores, especially desktops we do not dedicate one core to run protected sub-systems. That core can have a lot more security and can have lower performance. This kind of vertical partitioning favours Ic based kernel interfaces and AMD's HSA will enable such designs assuming hsa has the proper security support.
Std Intel seecurity does not go to the level Trustzone specifies security. FS also adds its extensions to secure boot which helps. There is a reason why AMD licenses TZ and plans to put a Cortex A5 as a sec subsystem in its x86 SoC.
Part of the reason is that the os security mode needed to run full Trustzone is kind of orthogonal to the ring levels of security in the std scheme of things.
The issue is that security has to be thought up ground up. Adding extensions like aes-ni, no execute bit et all over a period of time does not necessarily create a cohesive security model. For example above a certain level of security level, it is preferable to have a sec functional module rather than aes extensions. that function unit can have its own isolated ram, key storage and other isolation features. Which is what FS does and which by the way is not mandated by Trustzone. If I use the main Alu's functional unit for security processing, may leak keys through cache or create other channels for information leakage.