<story><title>Mel&apos;s Hack – The Missing Bits</title><url>https://melsloop.com/docs/mels-hack-the-missing-bits</url><text>New article on Mel&amp;#x27;s Loop project – an analysis of Mel Kaye&amp;#x27;s hack for his blackjack game for the RPC-4000 computer.&lt;p&gt;&amp;quot;This approach to coding is far from extinct. One often finds it in software teams, among some highly regarded – though less valued – members. If you&amp;#x27;ve spent several years in the industry or in Computer Science academia, you surely know this subspecies: the developer that replaces a straightforward loop with a series of auto-resolving promises, capped by a cryptic reducer, then revels in their teammates&amp;#x27; bewilderment at the sight of the new code. Hardly the personality that you&amp;#x27;d select for a coding legend.&amp;quot;
(ibid)</text></story><parent_chain></parent_chain><comment><author>YeGoblynQueenne</author><text>Hey, thanks for the shout out. I laughed out loud at being called a &amp;quot;Mel enthusiast&amp;quot; but it&amp;#x27;s totally true :)&lt;p&gt;&amp;gt;&amp;gt; Instead of running a test, Mel kept incrementing the value of the (A) field, as described in the story. This eventually led to an overflow of the entire register, provided the index register bit (X) was on – exactly as Nather remembered. Using 101 as the TBC opcode yields the following sequence:&lt;p&gt;&amp;gt;&amp;gt; The overflow would toggle the BCU on, causing the heretofore ineffective TBC to transfer control to the address in the (A) field, which was 0.&lt;p&gt;Wow. I kind of waved my hands at that solution, but you worked it out almost in full (short of actually coding it ... I guess there&amp;#x27;s no emulator for the RPC-4000 around? Someone should go and write one seeing as the architecture is mostly in the manuals and all. Someone... else &amp;gt;_&amp;gt;). Good stuff!&lt;p&gt;Btw, if you&amp;#x27;re looking for translations to more languages, there is a Greek one here:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;greektrans.blogspot.com&amp;#x2F;2010&amp;#x2F;06&amp;#x2F;mel.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;greektrans.blogspot.com&amp;#x2F;2010&amp;#x2F;06&amp;#x2F;mel.html&lt;/a&gt;&lt;p&gt;Complete with Greek-language annotations.</text></comment>
<story><title>Mel&apos;s Hack – The Missing Bits</title><url>https://melsloop.com/docs/mels-hack-the-missing-bits</url><text>New article on Mel&amp;#x27;s Loop project – an analysis of Mel Kaye&amp;#x27;s hack for his blackjack game for the RPC-4000 computer.&lt;p&gt;&amp;quot;This approach to coding is far from extinct. One often finds it in software teams, among some highly regarded – though less valued – members. If you&amp;#x27;ve spent several years in the industry or in Computer Science academia, you surely know this subspecies: the developer that replaces a straightforward loop with a series of auto-resolving promises, capped by a cryptic reducer, then revels in their teammates&amp;#x27; bewilderment at the sight of the new code. Hardly the personality that you&amp;#x27;d select for a coding legend.&amp;quot;
(ibid)</text></story><parent_chain></parent_chain><comment><author>kazinator</author><text>&amp;gt; &lt;i&gt;Rather, it stems from the obvious lack of real value that the hack added to the program. It&amp;#x27;s very unlikely that a standard loop would have degraded the program&amp;#x27;s performance in any noticeable way. Mel&amp;#x27;s testless loop was clearly a vain addition of complexity.&lt;/i&gt;&lt;p&gt;Firstly, there is a false premise here which is that the story is about a great programmer who worked hard to do nothing but add real value to a program. Obviously, this is not so.
The story makes it clear by including detail like &lt;i&gt;&amp;#x27;&amp;quot;Even the initializer is optimized&amp;quot;, [Mel] said proudly&amp;#x27;&lt;/i&gt;, where is it clear that Mel understands that the initializer runs only once, but he optimized it anyway. Some of what Mel did added value, and some of it was just done for Mel&amp;#x27;s own benefit of learning and self-actualization.&lt;p&gt;Secondly, it is not necessarily true that the testless loop isn&amp;#x27;t an optimization. We cannot assume that Mel was always optimizing for time. He probably optimized for code size in cases when optimizing for speed wouldn&amp;#x27;t make a difference.&lt;p&gt;If a program obeys the 80&amp;#x2F;20 rule, where 80% of its time is in 20% of its code, then you can make the biggest speed improvementsin 20% of the code. But then what do you do with the 80% of the code that doesn&amp;#x27;t execute often enough to make a difference? You can optimize that for &lt;i&gt;size&lt;/i&gt; to end up with a small program that is still blazingly fast.&lt;p&gt;Size doesn&amp;#x27;t follow any 80&amp;#x2F;20 rule: 100% of the size of the program is evenly spread into 100% of the code. Shaving an instruction from &lt;i&gt;anywhere&lt;/i&gt; makes it one instruction shorter, whether that instruction is in three levels of loop nesting, or initialization code that executes once.&lt;p&gt;Still, if the machine runs only one program, such as doing nothing else but providing that blackjack game, and if that program fits, there is no value in making it any smaller.</text></comment>