<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>

<channel>
	<title>Joe Auricchio &#187; Architecture</title>
	<atom:link href="http://joe.definitelynotsafe.com/category/architecture/feed" rel="self" type="application/rss+xml" />
	<link>http://joe.definitelynotsafe.com</link>
	<description>Just another WordPress weblog</description>
	<pubDate>Tue, 15 Jul 2008 14:42:48 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
	<language>en</language>
			<item>
		<title>Thoughts on the Atom</title>
		<link>http://joe.definitelynotsafe.com/thoughts-on-the-atom</link>
		<comments>http://joe.definitelynotsafe.com/thoughts-on-the-atom#comments</comments>
		<pubDate>Tue, 20 May 2008 05:15:51 +0000</pubDate>
		<dc:creator>Joe Auricchio</dc:creator>
		
		<category><![CDATA[Architecture]]></category>

		<guid isPermaLink="false">http://joe.definitelynotsafe.com/?p=239</guid>
		<description><![CDATA[Intel's new Atom microarchitecture targets embedded systems, bringing two new innovations to embedded ISAs: SMT and x86 binary compatibility. SMT will bring better performance on multithreaded workloads, but the Atom's heavy front end may consume too much power on simple monothreaded code. I don't think x86 compatibility is a particularly desirable property of an embedded system, though: nobody cares about binary compatibility back to MS-DOS, and the x86 community may not be ready for the board support issues of the embedded world.]]></description>
			<content:encoded><![CDATA[<p>The RISC vs CISC war isn&#8217;t over, and the next battle will be for handheld devices. Intel&#8217;s new Atom microarchitecture looks like a very interesting competitor to ARM and PowerPC in the &#8220;embedded systems with muscle&#8221; space (roughly: smartphones and set-tops). Hannibal nicely sums up the issue in an article that&#8217;s made the rounds of Slashdot et al, so I&#8217;ll let him do the talking for a few moments.</p>
<p><a href="http://arstechnica.com/articles/paedia/risc-vs-cisc-mobile-era.ars">RISC vs CISC in the Mobile Era</a></p>
<p>I&#8217;m surprised at how strongly Intel is now embracing SMT. The Core lost HyperThreading for power and heat concerns a few years ago, and it stayed out of Core 2. But this year, Nehalem brings back SMT&#8230; and it&#8217;s in Atom too!</p>
<p>SMT in an in-order low-power chip is an interesting choice. Historically, SMT was about performance (<i>not</i> about perf per watt). In 2000, if you had a big honkin&#8217; superscalar, you probably didn&#8217;t care about power consumption much. Hannibal makes the very strong and clear point that because of Atom&#8217;s x86 legacy (the excess of transistors burned on predecode, length decode, and complex-op microcode hardware), it&#8217;s impossible to follow the ARM Cortex strategy of building a tiny core and stamping them out (see also Sun Niagara!). The front-end is so heavy that its power cost <i>has</i> to be shared by/amortized over a few threads.</p>
<p>I&#8217;d suspect, for comparable parts, Atom will outperform Cortex on multithreaded workloads (no surprise), Cortex will beat Atom for complex single threads, and Cortex will use much less <i>power</i> than Atom on easy single threaded code.</p>
<p>Finally, I&#8217;m still not convinced by Intel&#8217;s &#8220;x86 everywhere&#8221; strategy. This is the embedded space, where different system boards share nothing in common. In answering the question, &#8220;What does this device look like to my code?&#8221; the ISA is the <i>least</i> interesting thing to examine. The embedded community has to support many many wildly different systems, and they do a very good job of it. The x86 community has not had any experience like this, and I don&#8217;t think giving them the <i>option</i> to adapt to this new world is necessarily a productive thing to do.<sup class='footnote'><a href='#fn-239-1' id='fnref-239-1'>1</a></sup></p>
<p>Case in point: the Linux i386 branch is almost exclusively intended for &#8220;PCs&#8221;&#8230; even a diskless workstation like Scott&#8217;s little Cyrix is way out in the boonies of supported systems. But Linux also supports <a href="http://www.linuxdevices.com/articles/AT4313418436.html">dozens of fantastically varied embedded systems</a>: I count 59 ARM-based, 27 MIPS-based, 22 PPC-based, and 22 others including Super-H, SHARC, Blackfin, Tensilica, and FPGA soft-cores. There are only ten x86-based embedded systems. It is the embedded community that can most effectively accommodate new devices. All x86 could bring to the table is an arrogant assumption that things &#8220;ought to work like they do on PCs&#8221; and binary compatibility with software nobody cares about. If I&#8217;m building a set-top box, I don&#8217;t care if it can run Word &#8216;97. That&#8217;s just not a selling point I see for the Atom.</p>
<div class='footnotes'>
<div class='footnotedivider'></div>
<ol>
<li id='fn-239-1'>Of course the PC world has many different devices, and Windows users have been dealing with driver problems as long as there have been PCs or drivers. But it&#8217;s one thing to have to track down the right driver for your old ISA sound card. It&#8217;s something completely different when your CPU talks to the sound chip over memory-mapped registers that go through a Spartan-3&#8217;s GPIO pins. <span class='footnotereverse'><a href='#fnref-239-1'>&#8617;</a></span></li>
</ol>
</div>
]]></content:encoded>
			<wfw:commentRss>http://joe.definitelynotsafe.com/thoughts-on-the-atom/feed</wfw:commentRss>
		</item>
	</channel>
</rss>
