<?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"
	>
<channel>
	<title>Comments on: Writing software as we design hardware</title>
	<atom:link href="http://www.rfc1149.net/blog/2006/05/22/writing-software-as-we-design-hardware/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.rfc1149.net/blog/2006/05/22/writing-software-as-we-design-hardware/</link>
	<description>Samuel Tardieu's dual-sided blog</description>
	<pubDate>Sun, 12 Oct 2008 12:52:21 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Samuel Tardieu</title>
		<link>http://www.rfc1149.net/blog/2006/05/22/writing-software-as-we-design-hardware/#comment-3139</link>
		<dc:creator>Samuel Tardieu</dc:creator>
		<pubDate>Tue, 23 May 2006 14:33:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.rfc1149.net/blog/2006/05/22/writing-software-as-we-conceive-hardware/#comment-3139</guid>
		<description>&lt;b&gt;Stéphane&#160;:&lt;/b&gt; I had to use another trick to make sure that the compiler doesn't gather all the ground planes into a common separated section; I made them constant so that they appear in the &lt;i&gt;text&lt;/i&gt; section of the executable instead of the &lt;i&gt;data&lt;/i&gt; one. Concerning your question about interpreted languages, this is not really a problem as this kind of safety net has to be built into the interpreter itself.

&lt;b&gt;Daniel&#160;:&lt;/b&gt; I didn't know this one

&lt;b&gt;Pierre&#160;:&lt;/b&gt; thank you for your excellent suggestions. I have added power decloupling, differential transmission and fuses all over my code. It looks like it is now bulletproof and will be able to run for decades without any glitch.</description>
		<content:encoded><![CDATA[<p><b>Stéphane&nbsp;:</b> I had to use another trick to make sure that the compiler doesn&#8217;t gather all the ground planes into a common separated section; I made them constant so that they appear in the <i>text</i> section of the executable instead of the <i>data</i> one. Concerning your question about interpreted languages, this is not really a problem as this kind of safety net has to be built into the interpreter itself.</p>
<p><b>Daniel&nbsp;:</b> I didn&#8217;t know this one</p>
<p><b>Pierre&nbsp;:</b> thank you for your excellent suggestions. I have added power decloupling, differential transmission and fuses all over my code. It looks like it is now bulletproof and will be able to run for decades without any glitch.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pierre</title>
		<link>http://www.rfc1149.net/blog/2006/05/22/writing-software-as-we-design-hardware/#comment-3096</link>
		<dc:creator>Pierre</dc:creator>
		<pubDate>Tue, 23 May 2006 12:04:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.rfc1149.net/blog/2006/05/22/writing-software-as-we-conceive-hardware/#comment-3096</guid>
		<description>Excellent article ! Several related ideas come to mind:

- power decoupling: declare at least one variable in every function you write and initialize it to a non-null value: this will create a small local power reservoir. In big functions, you may need two or more such variables, scattered at regular intervals throughout the source code.
- differential transmission (more noise immunity) : replace

   int f(int n) { return n }

   with

   int fa(int n) { return n; } int fb(int n) { return -n }
   int f(int n) { return (fa(n) - fb(n)) / 2 }

- fuses : protect sensitive/expensive functions from bogus/dangerous input

   int intfuse(int n) { if (n &#60; 1000000000) return n; else return 0 }
   int f(int v) { v = intfuse(v); /* ... */ }

   (ideally the fuse should be placed in a separate dynamically loaded object file for easier
   replacement in the field)

Your code will be even more tolerant to power fluctuations and noise!</description>
		<content:encoded><![CDATA[<p>Excellent article ! Several related ideas come to mind:</p>
<p>- power decoupling: declare at least one variable in every function you write and initialize it to a non-null value: this will create a small local power reservoir. In big functions, you may need two or more such variables, scattered at regular intervals throughout the source code.<br />
- differential transmission (more noise immunity) : replace</p>
<p>   int f(int n) { return n }</p>
<p>   with</p>
<p>   int fa(int n) { return n; } int fb(int n) { return -n }<br />
   int f(int n) { return (fa(n) - fb(n)) / 2 }</p>
<p>- fuses : protect sensitive/expensive functions from bogus/dangerous input</p>
<p>   int intfuse(int n) { if (n &lt; 1000000000) return n; else return 0 }<br />
   int f(int v) { v = intfuse(v); /* &#8230; */ }</p>
<p>   (ideally the fuse should be placed in a separate dynamically loaded object file for easier<br />
   replacement in the field)</p>
<p>Your code will be even more tolerant to power fluctuations and noise!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel</title>
		<link>http://www.rfc1149.net/blog/2006/05/22/writing-software-as-we-design-hardware/#comment-3092</link>
		<dc:creator>Daniel</dc:creator>
		<pubDate>Tue, 23 May 2006 11:30:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.rfc1149.net/blog/2006/05/22/writing-software-as-we-conceive-hardware/#comment-3092</guid>
		<description>This isn't by any chance a not-so-subtle dig at this crank:
http://pages.sbcglobal.net/louis.savain/Cosas/COSA.htm
is it?</description>
		<content:encoded><![CDATA[<p>This isn&#8217;t by any chance a not-so-subtle dig at this crank:<br />
<a href="http://pages.sbcglobal.net/louis.savain/Cosas/COSA.htm"  class="external">http://pages.sbcglobal.net/louis.savain/Cosas/COSA.htm</a><br />
is it?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stéphane Bortzmeyer</title>
		<link>http://www.rfc1149.net/blog/2006/05/22/writing-software-as-we-design-hardware/#comment-3081</link>
		<dc:creator>Stéphane Bortzmeyer</dc:creator>
		<pubDate>Tue, 23 May 2006 07:08:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.rfc1149.net/blog/2006/05/22/writing-software-as-we-conceive-hardware/#comment-3081</guid>
		<description>Did you examine the code produced by the compiler to see if there was any difference, specially after optimization? :-)

&#62; I encourage everyone to do the same thing, in every programming language.

Even if ground planes and intermediate registers actually do something in C, I doubt it will work in Python or Ruby :-)</description>
		<content:encoded><![CDATA[<p>Did you examine the code produced by the compiler to see if there was any difference, specially after optimization? <img src='http://www.rfc1149.net/blog/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>&gt; I encourage everyone to do the same thing, in every programming language.</p>
<p>Even if ground planes and intermediate registers actually do something in C, I doubt it will work in Python or Ruby <img src='http://www.rfc1149.net/blog/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
</channel>
</rss>
