<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Macintosh: Intel Inside, And What It Might Mean For PalmSource</title>
	<atom:link href="http://tewha.net/2005/06/macintosh-intel-inside-and-what-it-might-mean-for-palmsource/feed/" rel="self" type="application/rss+xml" />
	<link>http://tewha.net/2005/06/macintosh-intel-inside-and-what-it-might-mean-for-palmsource/</link>
	<description>A blog on technical stuff by Steven Fisher. Cat pictures not included.</description>
	<pubDate>Tue, 06 Jan 2009 08:47:03 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Ben Combee</title>
		<link>http://tewha.net/2005/06/macintosh-intel-inside-and-what-it-might-mean-for-palmsource/comment-page-1/#comment-25</link>
		<dc:creator>Ben Combee</dc:creator>
		<pubDate>Sat, 04 Jun 2005 17:23:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.objectsatrest.com/2005/06/macintosh-intel-inside-and-what-it-might-mean-for-palmsource/#comment-25</guid>
		<description>Well, in a sense, this is what Transmeta was doing -- they had a sophisticated VLIW execution engine and code that translated x86 to it.  ARM chips also use this concept; the Thumb instruction set is a front-end for their 32-bit instruction where single 16-bit-long instructions get expanded into the full size ones.  I can't say this is what Intel would be doing, but it's certainly possible.</description>
		<content:encoded><![CDATA[<p>Well, in a sense, this is what Transmeta was doing &#8212; they had a sophisticated VLIW execution engine and code that translated x86 to it.  ARM chips also use this concept; the Thumb instruction set is a front-end for their 32-bit instruction where single 16-bit-long instructions get expanded into the full size ones.  I can&#8217;t say this is what Intel would be doing, but it&#8217;s certainly possible.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steven Fisher</title>
		<link>http://tewha.net/2005/06/macintosh-intel-inside-and-what-it-might-mean-for-palmsource/comment-page-1/#comment-24</link>
		<dc:creator>Steven Fisher</dc:creator>
		<pubDate>Sat, 04 Jun 2005 07:39:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.objectsatrest.com/2005/06/macintosh-intel-inside-and-what-it-might-mean-for-palmsource/#comment-24</guid>
		<description>Come to think of it, this whole idea of decoding personalities has been around for a while, hasn't it? I seem to remember reading that this would change the world in the days when the Powerbook Duo 230 in 1992 or so, and that's only because that's when I started really stuff by the &lt;em&gt;really&lt;/em&gt; clever monkeys.

It could be that it makes sense to not only standardize the scheduling/execution units, but to just tack on decoding units. Want to compete with the ARM? Throw in an ARM decoder. Want to complete with a PowerPC? Throw one of them in, too. x86? Here ya go, we got one of those too. All in the same chip. I know these percentages are insane, but of the decoding unit is 60%, it might not make any sense at all. 1% and it probably would. I wonder where would it stop making sense, and if we're above or below that right now.

There's other implications here, too. The x86 decoding unit fails testing but the PowerPC one doesn't? Ship it as a PowerPC-only chip.

Huh. Thanks for the thoughts, Ben. :)</description>
		<content:encoded><![CDATA[<p>Come to think of it, this whole idea of decoding personalities has been around for a while, hasn&#8217;t it? I seem to remember reading that this would change the world in the days when the Powerbook Duo 230 in 1992 or so, and that&#8217;s only because that&#8217;s when I started really stuff by the <em>really</em> clever monkeys.</p>
<p>It could be that it makes sense to not only standardize the scheduling/execution units, but to just tack on decoding units. Want to compete with the ARM? Throw in an ARM decoder. Want to complete with a PowerPC? Throw one of them in, too. x86? Here ya go, we got one of those too. All in the same chip. I know these percentages are insane, but of the decoding unit is 60%, it might not make any sense at all. 1% and it probably would. I wonder where would it stop making sense, and if we&#8217;re above or below that right now.</p>
<p>There&#8217;s other implications here, too. The x86 decoding unit fails testing but the PowerPC one doesn&#8217;t? Ship it as a PowerPC-only chip.</p>
<p>Huh. Thanks for the thoughts, Ben. <img src='http://tewha.net/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steven Fisher</title>
		<link>http://tewha.net/2005/06/macintosh-intel-inside-and-what-it-might-mean-for-palmsource/comment-page-1/#comment-23</link>
		<dc:creator>Steven Fisher</dc:creator>
		<pubDate>Sat, 04 Jun 2005 07:30:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.objectsatrest.com/2005/06/macintosh-intel-inside-and-what-it-might-mean-for-palmsource/#comment-23</guid>
		<description>It's definitely a strange theory, but I think it's a little less strange than Apple's new strategy being "Mac OS X on x86 next year, and you'll all come with us, right?" That sounds like taking the worst of Adam Osborne's strategy ("what we've got now is crap, but wait to next year") with something uniquely Apple ("we told you what we're switching to was crap last year, but now it's better!").

Hmm, the idea of a chip that could run both instruction sets is really intriguing. Any idea what portion of the P4/PM is dedicated to x86 decoding?

(Btw, sorry for the article editing. I'm switching the article to MarkDown instead of HTML behind the scenes. I really hate the a href="blahblah" link title /a syntax, and I can't believe how smoothly it's going.)</description>
		<content:encoded><![CDATA[<p>It&#8217;s definitely a strange theory, but I think it&#8217;s a little less strange than Apple&#8217;s new strategy being &#8220;Mac OS X on x86 next year, and you&#8217;ll all come with us, right?&#8221; That sounds like taking the worst of Adam Osborne&#8217;s strategy (&#8221;what we&#8217;ve got now is crap, but wait to next year&#8221;) with something uniquely Apple (&#8221;we told you what we&#8217;re switching to was crap last year, but now it&#8217;s better!&#8221;).</p>
<p>Hmm, the idea of a chip that could run both instruction sets is really intriguing. Any idea what portion of the P4/PM is dedicated to x86 decoding?</p>
<p>(Btw, sorry for the article editing. I&#8217;m switching the article to MarkDown instead of HTML behind the scenes. I really hate the a href=&#8221;blahblah&#8221; link title /a syntax, and I can&#8217;t believe how smoothly it&#8217;s going.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben Combee</title>
		<link>http://tewha.net/2005/06/macintosh-intel-inside-and-what-it-might-mean-for-palmsource/comment-page-1/#comment-22</link>
		<dc:creator>Ben Combee</dc:creator>
		<pubDate>Sat, 04 Jun 2005 07:22:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.objectsatrest.com/2005/06/macintosh-intel-inside-and-what-it-might-mean-for-palmsource/#comment-22</guid>
		<description>Interesting idea... I know current Pentium IV and Pentium-M chips are implemented with a decoder front-end that converts x86 instructions to a simpler RISC-based form for scheduling and execution.  I wonder how difficult it would be to add a PowerPC front end to that execution unit, giving a chip that can run both x86 and PPC code depending on the CPU mode.</description>
		<content:encoded><![CDATA[<p>Interesting idea&#8230; I know current Pentium IV and Pentium-M chips are implemented with a decoder front-end that converts x86 instructions to a simpler RISC-based form for scheduling and execution.  I wonder how difficult it would be to add a PowerPC front end to that execution unit, giving a chip that can run both x86 and PPC code depending on the CPU mode.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
