- Tuesday, 24 November 2009
- INQ Mobile
- RSS
Potatoes are more intelligent than grass because people can eat them - Gurdjieff
VIA goes for ARM
Ignoring its own kit
Thursday, 12 March 2009, 15:17
DESPITE the fact it has been playing around with chips of its own, Via has opted to shove an ARM9 under the bonnet of its new multimedia capable system on a chip (SoC).
An early version of the Prizm SoC, called the VT8500, is available in a Windows CE-ready computer, will cost $100, and will be aimed at networked multimedia embedded systems.
But Via has its own x86-based processors and chipsets for the mobile and embedded markets, including the Eden and Eden ULV, the C7-M ULV, and most recently, the 64-bit Nano.
Quite why it is still horsing around with ARM when it has chips of its own is anyone's guess. µ
L'Inq
Windows for Devices
Share this:
Share
Advertisement
Subscribe to the INQ Newsletter
Sign-up for the INQBot weekly newsletter
INQ Whitepapers
Business Intelligence Software
Customer Relationship Management (CRM)
Enterprise Accounting Software
Enterprise Resource Planning (ERP)
Enterprise Systems Management
Jobs
Advertisement
INQ Poll
It has been a long time since VIA brought anything competitive to market
Realists at head office probably realized that their x86 gear still wasn't up to snuff and ARM's CPUs simply kick ass for energy efficiency.
It is estimated that keeping x86 backwards compatible takes about 30% of the silicon die space. That's a lot of space in an embedded part.
Dave - see http://groups.google.com/group/comp.arch/msg/ecf4b72cb8b21754 , which is a post by one of the Opteron CPU architects on just how much overhead x86 actually causes. Hint: not 30%.
On the other hand, the ARM926EJ runs an older version of the ARM instruction set and is a fairly slow core. It's too bad they didn't use one of the newer ARM cores.
You can't just locate a chip region and say "Look, all x86 overhead is isolated there".
About decoding. As small the decoder area is, it still induces comparatively heavy overhead. Modern x86 implementations devote *several* pipeline stages to decoding. Non x86 cpus usually get it done with just one. They tend to have much shorter pipelines. Shorter pieline means lesser penalty when any of speculative mechanism in CPU logic fails. And this is just an example. You pay penalty for x86 all the time.
Now, remember that x86 relates also to SOFTWARE, not just to HARDWARE. You not only have to deal with inefficiency of DEcoding. There is also inefficiency of ENcoding. Horribly assymetric ISA with tiny number of registers is a nightmare for optimising compiler. You spit out spaghetti of superfluous dependencies and memory traffic that on any sane ISA wouldn't exist. When it's consumed by x86 CPU, it engages ALL resources, not just decoders.