<?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: Register vs. stack based VMs</title>
	<atom:link href="http://shape-of-code.coding-guidelines.com/2009/09/17/register-vs-stack-based-vms/feed/" rel="self" type="application/rss+xml" />
	<link>http://shape-of-code.coding-guidelines.com/2009/09/17/register-vs-stack-based-vms/</link>
	<description></description>
	<lastBuildDate>Sun, 12 Feb 2012 22:01:48 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Ian Rogers</title>
		<link>http://shape-of-code.coding-guidelines.com/2009/09/17/register-vs-stack-based-vms/comment-page-1/#comment-736</link>
		<dc:creator>Ian Rogers</dc:creator>
		<pubDate>Fri, 13 Nov 2009 16:49:22 +0000</pubDate>
		<guid isPermaLink="false">http://shape-of-code.coding-guidelines.com/?p=119#comment-736</guid>
		<description>What is often not considered when comparing stack and register based VMs is that SSA form (a corner stone of any reasonable optimizing JIT compiler) falls out for free in a stack based VM. In particular anything on the stack at the end of a basic block needs to have a phi node. Calling Java VMs stack based is also confusing as the local variables could be thought of as registers, and are in simple JITs often mapped to fixed registers.

I think the biggest complaint about register based VMs is going to be that they make assumptions of some underlying architecture that they are targeting. Given this and the extra work they must do to construct an SSA form, I think they need to work harder to convince the world that they are better than stack based VMs (the paper cited above included).</description>
		<content:encoded><![CDATA[<p>What is often not considered when comparing stack and register based VMs is that SSA form (a corner stone of any reasonable optimizing JIT compiler) falls out for free in a stack based VM. In particular anything on the stack at the end of a basic block needs to have a phi node. Calling Java VMs stack based is also confusing as the local variables could be thought of as registers, and are in simple JITs often mapped to fixed registers.</p>
<p>I think the biggest complaint about register based VMs is going to be that they make assumptions of some underlying architecture that they are targeting. Given this and the extra work they must do to construct an SSA form, I think they need to work harder to convince the world that they are better than stack based VMs (the paper cited above included).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Derek-Jones</title>
		<link>http://shape-of-code.coding-guidelines.com/2009/09/17/register-vs-stack-based-vms/comment-page-1/#comment-649</link>
		<dc:creator>Derek-Jones</dc:creator>
		<pubDate>Fri, 18 Sep 2009 17:03:56 +0000</pubDate>
		<guid isPermaLink="false">http://shape-of-code.coding-guidelines.com/?p=119#comment-649</guid>
		<description>Good point Alex, JIT compilation is an important issue.  Which architecture is best from the JIT perspective?  I suspect that the same amount of information about the code can be extracted from both architectures and given sufficient time the generated code quality will be essentially the same.

The purpose of JIT code generation is to improve the performance of a currently executing program, so it cannot hang around looking for fancy optimizations that sometimes produce savings.  Given a fixed amount of processing time would faster machine code be generated from a register or stack VM? &lt;a href=&quot;www.trl.ibm.com/people/ishizaki/papers/Ishizaki2003oopsla.pdf&quot; rel=&quot;nofollow&quot;&gt;Effectiveness of Cross-Platform Optimizations
for a Java Just-In-Time Compiler&lt;/a&gt; provides time/quality numbers for a stack VM, I don&#039;t know of any similar figures for a register based VM.

Of course if the architecture of a register VM is close to that of the target hardware the JIT generator will have some of its work done for &#039;free&#039;, eg, register allocation.  Google&#039;s Davik VM is a long way from looking like an Intel x86, an &lt;a href=&quot;http://en.wikipedia.org/wiki/ARM_architecture&quot; rel=&quot;nofollow&quot;&gt;Arm processor&lt;/a&gt; would be a much better fit.

That is very interesting information on compiled Cobol performance (MicroFocus used to call the NCG&#039;s &#039;Optimizers&#039;, because they optimized performance).  I last worked on one of these &#039;optimizers&#039; over 15 years ago, and things might have changed a bit (perhaps bits of the Sparc generator are still in use :-O), and what was considered important back then was generating good code for data movement involving various combinations of source/destination storage alignment + fancy algorithms for doing arithmetic on values represented various non-two&#039;s compliment forms.  I recall that some analysis we did showed that only 5% of code had to be handled by calls to library functions.

I am surprised to hear that the performance of code generated by going via the JVM is comparable to that produced by MicroFocus&#039;s NCG.  Perhaps you are running on a platform where misaligned storage accesses don&#039;t incur a large penalty or perhaps there is a high percentage of library calls?</description>
		<content:encoded><![CDATA[<p>Good point Alex, JIT compilation is an important issue.  Which architecture is best from the JIT perspective?  I suspect that the same amount of information about the code can be extracted from both architectures and given sufficient time the generated code quality will be essentially the same.</p>
<p>The purpose of JIT code generation is to improve the performance of a currently executing program, so it cannot hang around looking for fancy optimizations that sometimes produce savings.  Given a fixed amount of processing time would faster machine code be generated from a register or stack VM? <a href="www.trl.ibm.com/people/ishizaki/papers/Ishizaki2003oopsla.pdf" rel="nofollow">Effectiveness of Cross-Platform Optimizations<br />
for a Java Just-In-Time Compiler</a> provides time/quality numbers for a stack VM, I don&#8217;t know of any similar figures for a register based VM.</p>
<p>Of course if the architecture of a register VM is close to that of the target hardware the JIT generator will have some of its work done for &#8216;free&#8217;, eg, register allocation.  Google&#8217;s Davik VM is a long way from looking like an Intel x86, an <a href="http://en.wikipedia.org/wiki/ARM_architecture" rel="nofollow">Arm processor</a> would be a much better fit.</p>
<p>That is very interesting information on compiled Cobol performance (MicroFocus used to call the NCG&#8217;s &#8216;Optimizers&#8217;, because they optimized performance).  I last worked on one of these &#8216;optimizers&#8217; over 15 years ago, and things might have changed a bit (perhaps bits of the Sparc generator are still in use :-O), and what was considered important back then was generating good code for data movement involving various combinations of source/destination storage alignment + fancy algorithms for doing arithmetic on values represented various non-two&#8217;s compliment forms.  I recall that some analysis we did showed that only 5% of code had to be handled by calls to library functions.</p>
<p>I am surprised to hear that the performance of code generated by going via the JVM is comparable to that produced by MicroFocus&#8217;s NCG.  Perhaps you are running on a platform where misaligned storage accesses don&#8217;t incur a large penalty or perhaps there is a high percentage of library calls?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex Turner</title>
		<link>http://shape-of-code.coding-guidelines.com/2009/09/17/register-vs-stack-based-vms/comment-page-1/#comment-648</link>
		<dc:creator>Alex Turner</dc:creator>
		<pubDate>Fri, 18 Sep 2009 06:47:23 +0000</pubDate>
		<guid isPermaLink="false">http://shape-of-code.coding-guidelines.com/?p=119#comment-648</guid>
		<description>This is a very interesting post - thanks.

I see your thoughts about register based vms but have some other considerations which you don&#039;t seem to have addressed.  In the case of the JVM the stack based vm is Just In Time compiling the byte code as methods connect to the execution graph. This means that the performance of the byte code is less important than its ability to describe the intention of the code in such a way that the optimizer can take advantage.

In a similar but different way, the Micro Focus vm produces intermediate code. Why is this called intermediate code, because the NCG (native code generator) is usually used to compile this down to bare metal instructions.

Declare interest - I work for MF!

In recent comparisons, we have been finding that COBOL compiled to JVM byte codes and then run using the JITing JVM compares well with COBOL compiled to int code and then put through the optimizing NCG to give native code.

What does this mean? I think it indicates that the benefits you are seeing with register based VMs, whilst real, are largely irrelevant when the VM code is compiled down to bare metal before execution.

Best wishes - AJ</description>
		<content:encoded><![CDATA[<p>This is a very interesting post &#8211; thanks.</p>
<p>I see your thoughts about register based vms but have some other considerations which you don&#8217;t seem to have addressed.  In the case of the JVM the stack based vm is Just In Time compiling the byte code as methods connect to the execution graph. This means that the performance of the byte code is less important than its ability to describe the intention of the code in such a way that the optimizer can take advantage.</p>
<p>In a similar but different way, the Micro Focus vm produces intermediate code. Why is this called intermediate code, because the NCG (native code generator) is usually used to compile this down to bare metal instructions.</p>
<p>Declare interest &#8211; I work for MF!</p>
<p>In recent comparisons, we have been finding that COBOL compiled to JVM byte codes and then run using the JITing JVM compares well with COBOL compiled to int code and then put through the optimizing NCG to give native code.</p>
<p>What does this mean? I think it indicates that the benefits you are seeing with register based VMs, whilst real, are largely irrelevant when the VM code is compiled down to bare metal before execution.</p>
<p>Best wishes &#8211; AJ</p>
]]></content:encoded>
	</item>
</channel>
</rss>

