<?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: Power PC dumped</title>
	<atom:link href="http://blog.affien.com/archives/2005/06/06/power-pc-dumped/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.affien.com/archives/2005/06/06/power-pc-dumped/</link>
	<description>A few thoughts</description>
	<lastBuildDate>Tue, 02 Mar 2010 14:24:18 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Bas Westerbaan</title>
		<link>http://blog.affien.com/archives/2005/06/06/power-pc-dumped/comment-page-1/#comment-719</link>
		<dc:creator>Bas Westerbaan</dc:creator>
		<pubDate>Wed, 08 Jun 2005 16:44:44 +0000</pubDate>
		<guid isPermaLink="false">http://blog.w-nz.com/archives/2005/06/06/power-pc-dumped/#comment-719</guid>
		<description>Larger binaries mean more to load and to look through when starting an executable. It also means there is more to install and all. But indeed, when it has loaded there isn&#039;t a lot of difference. But I guess people should mind their size of executables and libraries to double.

The emulation shouldn&#039;t be a lot of a problem for these days emulation can be done by using JIT&#039;s or AOT&#039;s. Basicly by either converting the opcodes of one executable to be compatible with another architecture or to either do that at runtime. Both will most certainly cause a drop in speed but it wont be that much of a drop as compiling for x86 generic instead of for instane amd athlon.

But I heard that they are to release normal MacOSX and I-MacOSX. I-Mac would be the one with Intel executables. So code size wouldn&#039;t be an issue except for third parties wanting to deliver their product in one download/disk/etc instead of multiple.</description>
		<content:encoded><![CDATA[<p>Larger binaries mean more to load and to look through when starting an executable. It also means there is more to install and all. But indeed, when it has loaded there isn&#8217;t a lot of difference. But I guess people should mind their size of executables and libraries to double.</p>
<p>The emulation shouldn&#8217;t be a lot of a problem for these days emulation can be done by using JIT&#8217;s or AOT&#8217;s. Basicly by either converting the opcodes of one executable to be compatible with another architecture or to either do that at runtime. Both will most certainly cause a drop in speed but it wont be that much of a drop as compiling for x86 generic instead of for instane amd athlon.</p>
<p>But I heard that they are to release normal MacOSX and I-MacOSX. I-Mac would be the one with Intel executables. So code size wouldn&#8217;t be an issue except for third parties wanting to deliver their product in one download/disk/etc instead of multiple.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eamon Nerbonne</title>
		<link>http://blog.affien.com/archives/2005/06/06/power-pc-dumped/comment-page-1/#comment-718</link>
		<dc:creator>Eamon Nerbonne</dc:creator>
		<pubDate>Wed, 08 Jun 2005 15:04:11 +0000</pubDate>
		<guid isPermaLink="false">http://blog.w-nz.com/archives/2005/06/06/power-pc-dumped/#comment-718</guid>
		<description>There&#039;s no reason the larger executables should be slower, as only the &quot;correct&quot; half of the executable will ever be loaded by the OS and thus the foreign instructions won&#039;t be trashing cache-lines and perhaps not even reside in memory.

The intel processors will not support the old instructions, and as such there won&#039;t be any optimizing for common opcodes, or optimizing for it or whatnot.  PowerPC instructions that need to be executed will execute on a simulated G3, and will do so at a much slower speed that native execution.

i.e. Recompiled software will probably run faster (assuming the intel chips are faster, which they basically are), and some software will run really slow because it uses emulation.

Code size remains an issue, but disks are so large, and data so much more of a bit-consumer, that I don&#039;t think the increased executable size will really matter at all.</description>
		<content:encoded><![CDATA[<p>There&#8217;s no reason the larger executables should be slower, as only the &#8220;correct&#8221; half of the executable will ever be loaded by the OS and thus the foreign instructions won&#8217;t be trashing cache-lines and perhaps not even reside in memory.</p>
<p>The intel processors will not support the old instructions, and as such there won&#8217;t be any optimizing for common opcodes, or optimizing for it or whatnot.  PowerPC instructions that need to be executed will execute on a simulated G3, and will do so at a much slower speed that native execution.</p>
<p>i.e. Recompiled software will probably run faster (assuming the intel chips are faster, which they basically are), and some software will run really slow because it uses emulation.</p>
<p>Code size remains an issue, but disks are so large, and data so much more of a bit-consumer, that I don&#8217;t think the increased executable size will really matter at all.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bas Westerbaan</title>
		<link>http://blog.affien.com/archives/2005/06/06/power-pc-dumped/comment-page-1/#comment-705</link>
		<dc:creator>Bas Westerbaan</dc:creator>
		<pubDate>Mon, 06 Jun 2005 18:19:25 +0000</pubDate>
		<guid isPermaLink="false">http://blog.w-nz.com/archives/2005/06/06/power-pc-dumped/#comment-705</guid>
		<description>In any case they still will require support for a whole new architecture which means either a drop in speed or either an increase in size. (they have to choose whether to optimize for both architectures or just use common (slower) opcodes instead)</description>
		<content:encoded><![CDATA[<p>In any case they still will require support for a whole new architecture which means either a drop in speed or either an increase in size. (they have to choose whether to optimize for both architectures or just use common (slower) opcodes instead)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Mientjes</title>
		<link>http://blog.affien.com/archives/2005/06/06/power-pc-dumped/comment-page-1/#comment-703</link>
		<dc:creator>Rob Mientjes</dc:creator>
		<pubDate>Mon, 06 Jun 2005 15:58:08 +0000</pubDate>
		<guid isPermaLink="false">http://blog.w-nz.com/archives/2005/06/06/power-pc-dumped/#comment-703</guid>
		<description>Not necessarily. I still think Intel might be doing PPC chips and/or WiMax and the DRM they recently rolled out silently. We&#039;ll see. One hour to go...</description>
		<content:encoded><![CDATA[<p>Not necessarily. I still think Intel might be doing PPC chips and/or WiMax and the DRM they recently rolled out silently. We&#8217;ll see. One hour to go&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
