Compiler: use and prove asm

Here's a compiler switch I would like to see:

• Use the assembly code I give you (or some other forfm - RTL, transformed C code, etc.)
• But you, Mr. Compiler, should do a formal equivalence proof
• using various command line switches
• heck, I can even sketch the steps of the proof.  But I want you, the compiler, to chedck it.

Reason: oftentimes I optimize code by

1. Looking at compiler output
2. Handwriting assembly
3. Then trying to figure out compiler switches to cause the compiler to GENERATE this code.

Seems wasteful, since I already know the code that I want the compiler to generate.

It is often easier to verify equivalence of unoptimized and optimized form than it is to generate the optimized form.  Similarly, it is often easier to check a proof than it is to generate a proof.

Moreover, if you can specify code generation for just a small subset, then you can let the compiler do what it does well: the bookkeeping to connect that small subset to the rest of the world.

Exercise Machines

I am considering an exercise machine for home, since since my new house is further away from any health club than my old was. Talked to the repairman at my health club, about reliability. He said "Don't buy Sears or Walmart... Reputable brands like Precor..." Don't place in a basement or garage. Temperature fluctuations and moisture. Ellipticals are quite reliable. Treadmills break more often - motors. Stationary "spin" bicycles break surprisingly often, even though simple: perhaps because users "crank". The Precor AMT http://www.precor.com/products/en/home/amt/amtr-835-adaptive-motion-trainer breaks a lot. He is constantly repairing. But it is also most popular machine in gym. He thinks any home machine of any reputable brand will bne reliable enough, since used far less than at a health club. Rowing machines, such as http://concept2.com/us/indoorrowers/, are reliable, and really easy to repair. Parts like bicycle chains easy to find. However, most users do not know how to use. Electronics is the least reliable part. Then motors. He spoke highly of the Versaclimber, www.versaclimber.com, saying quite simple, easy to repairt, and a good workout. Also one of my favorite machines, although so intense / hurts my back so that I cannot do an hour on it.

Personal versus Version Control Log

I keep a log. ~/LOG. (Actually, I really need to keep a personal ~/LOG and ~/work/LOG, since the latter may belong to company. But thats another issue.) There is redundancy between my personal LOG and the log messages checked into a version control log. Like Mercurial, CVS, RCS, SVN, git. I often find myself writing similar messages into both mer version control log and my personal log. Cutting and pasting when I remember to. (Unfortunately, hg's integration with emacs' VC mode makes the cut and pasting a bit harder, since it removes the buffer in which the log message was being written as soon as checked in. Old RCS mode was more convenient, since it just pushed that buffer down in the stack, and I could easily go back and get the text. Not so hard to do an hg log and then cut5 and paste, but often too much hassle.) This is an example of the need for a multicast. Just like I sometimes want text to go to botyh my blog and my wiki, and USEnet comp.arch, and ... I also sometims want what I have written to go to version control log and personal ~/LOG (and maybe work ~/work/LOG, and ...) Cut and paste is okay if I weren't doing it so much. But since I do it so much I want something more convenient. How can I say it is tioo much hassle: because I often don't propagate stuff to all the logs I should.

Expressing fetch-old-and-do-new in a High Level Language

Quite often I find myself wanting to test the old value of some variable, using that to go into an IF, while then or soon thereafter setting a new value.

For example:

  our $titles_already_printed;
  sub print_titles {
     if( ! $titles_already_printed ) {
         print "TITLES...";
     }
     $titles_already_printed = 1;
  }

This doesn't look so bad if it is a simple variable:

  our $f;
  sub print_titles {
     if( ! $f ) {
         print "TITLES...";
     }
     $f = 1;
  }

But it can be painful if the flag variable iws accessed via a long and complicated path:

  our %titles_already_printed;
  sub print_titles {
     my $titles = shift;
     if( ! $titles_already_printed{$titles} ) {
         print "TITLES...";
     }
     $$titles_already_printed{$titles} = 1;
  }

And there can be more than one way of expessuing it:

  our %titles_already_printed;
  sub print_titles {
     my $titles = shift;
     if( $titles_already_printed{$titles} ) {
         return;
     }
     print "TITLES...";
     $$titles_already_printed{$titles} = 1;
  }

The return form is convenient for functions - but only if it is correct to return. I have seen quite a few bugs caused by such returns, when there is later code (perhaps added later) that should not be skipped by the return. The first form is convenient for straight line code, not wrapped in a function. It is annoying that refactoring code from straight line to function may sometimes require changing its control flow structure. Here are some other forms: First, separating the flag manipulation from the action:

  our %titles_already_printed;
  sub print_titles {
     my $titles = shift;

     my $old_resukt = exists $titles_already_printed{$titles};
     $titles_already_printed{$titles} = 1;
 
    if( $old_result ) {
         return;
     }
     print "TITLES...";
  }

You can probably see where I am going. Would it not be nice to not have the repetition? Something like

  our %titles_already_printed;
  sub print_titles {
     my $titles = shift;

     my $old_result = 
        lambda_define_and_invoke_here( NAME = $titles_already_printed{$titles} ) {
            return_value = exists name;
            NAME = 1;
        }
 
    if( $old_result ) {
         return;
     }
     print "TITLES...";
  }

Purely syntactic sugar, but...

• lambda_define_and_invoke_here defines a lambda function, a code block, in part to get parameterization so a shiort NAME can be used. It is defined and used immediatekly, so that we don't have to repeat ourselves by defining it associated with a name, and then immediately invoking that lambda name.
• Something like Jensen's device, name substitution, is used for NAME. In this example because $titles_already_printed{$titles} doesn't exist at the time of invocation. If that weren't an issue, a non-Jensen's device lvalue could be used. Extend that to a special lvalue for $titles_already_printed{$titles}, that creates $titles_already_printed{$titles} if it doesn't already exist and is later assigned to. An "potential lvalue for an ordinary lvalue that may not exist yet".
• return_value used so that we don't have to obscure things by creating a tmp for the old value.

This is purely syntactic sugar, but... I see this code a lot. But it is often slightly different. The purpose of an HLL is to make expresion easier and less error prone. Note: I am NOT talking about fetch-and-op or compare-and-swap for purposes of parallel programing synchronization - although obviously related. And, bonus if idioms expressed this way could be automatically translated to hardware atomic RMWs.

Focus on the focus window

I wonder if I should code stuff to bring the window I am working on the the center of my field of view, while moving other windows to the side. Again, related to more screens?

Shells tightly bound to directory?

I am noticing a pattern: I have long used emacs shell windows. But for some reasion more and more I am creating shell windows that are intended to be tightly bound to their directory. Whose name is their directiry. Where it gets confusing if I chdir in them. In fact, have had errors when I quickly type keystrokes to switch to a shell window command expecting to be in dir PROBLEM: had changed away from dir, deliberately or by accident I am beginning to wonder about DISABLING chdir in that sort of shell window. Or at least making it a bit more onerous. Why this is happening more now than in the past, I dunno. Possibly because I have more screens. --- Similar happens for xterms, but I use xterms much less often than I use emacs shell windows.

Understanding Exogenous shocks to Startups and Conditional Prophecy

http://cdixon.org/2011/12/07/growth-curves-of-startups/ 



I remember first observing this when I worked at Bessemer. For example, there was a startup that supplied services to video websites. For years, the company soldiered along, barely growing. Then, suddenly, YouTube blew up and this company took off along with it. 


As a founder, these exogenous shocks are out of your control, but you can 1) understand what exogenous shocks you depend on, 2) try to guess when those shocks will hit, 3) manage your runway so you survive long enough for them to hit.

This sounds very much related to my classification of prophecy or prediction:

There are 4 types of prophets:

(1) False prophets who are always or usually wrong, or are right by random chance. These are common.

(2) Accurate prophets, who can predict exactly what is going to happen, exactly when it is going to happen.  These are exceedingly rare.

(3) Eventual prophets, whose predictions, oft repeated, almost always eventually come true.  Here are some from the past, and some from the near future: "Computers will fit on your desk".  "Tablet computers will one day be popular." "Some day, computers will be worn, not carried, and will display on your glasses, contact lenses, directly onto the back of your eyes, or direct neural connect". Nobody with a clue will be surprised by the last set of eventual predictions coming true: the problem is knowing when, and how.  How to make it happen, and how to profit by it happening.

The final class of prophet is, I think, the most interesting, because it is sometimes attainable and more useful than anything except accurate prophecy:

(4) Conditional or contingent prophets:  they may not be able to predict exactly when something will happen, but they can make predictions about dependency graphs of events.  For example, referring to Chris Dixon's blog post "If internet video ever takes off (like YouTube eventually did) then there will be a market for video services for websites."  Or let me try: "Contact lens displays may take off (a) when nearly transparent pixels dense enough to be circa 1Mp on the size of a contact lens can be achieved, (b) when signals (whether by wire or non-wire (not necessarily electromagnetic wireless) can draw (not refresh) such pixels on a device, and (c) when a standby device <0.1W powered by energy harvesting can always run, and wake up a more power huingry device when needed).

When I helped start Intel's Microprocessor Research Lab I created several such dependency graphs.  Note: not just simple chains, since there may be more than one way at arriving at a result.