🚀 go-pugleaf

In article <1990Jul30.183426.26506@lth.se>, bengtl@maths.lth.se (Bengt Larsson) writes:
> In article <2413@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

			.....................

> >comp:	some code;
> >	texp -= expr;
> >	if(texp < 0) branchto bad;
> >	....
> >
> >bad:	more code;
> >	unbranchto comp;
> 
> Which, in a slightly more structured way would be
> 
> comp: 	some code;
> 	texp -= expr;
> 	if (texp < 0) {
				This was corrected by Mr.Larson in a subsequent 				post.
> 		more code;
> 		goto comp;
> 	}
> 
> wouldn't it? 
> 
> Are you worried that "more code" will mostly not be executed, and therefore
> you move it, reverse the test, branch and branch back?

This is definitely the case.

> Is the execution time of your code that critical? 

This block of code is likely to be executed at least tens of thousands of times,
and quite likely tens of millions.  It is code for refilling a buffer to be 
used in Monte Carlo calculations.

> And what in the world is an "unbranch to"? What sets it apart from a 
> "branchto" (+ an optimizer)?

Not much.  It is an instruction to the compiler that that particular
form of "optimization" is to be carried out, whether or not the compiler
recognizes it.  A possible HLL way to do this would be

 comp: 	some code;
 	texp -= expr;
 	if (texp < 0) remote {
 		more code;
 		goto comp;
		}

	.........................
 
 
> It may be slower. But: do you value your own time? How many hours does it
> take you to implement an algorithm if you micro-manage it like that? Is
> it going to be run ten billion times? Is it going to be sold to ten thousand
> customers? Is it really worth it?

This part of the code ten million, anyhow.
 
> If you can achieve 80% of the speed in 20% of the programming time,
> isn't it worth it? 

More likely 30% of the speed in 120% of the programming time.  The HLL
syntax is that stilted compared to the machine design.

I suspect that if people were taught the structure of the hardware, that
they would do these things without effort.  At least some of them would,
which is much better than the present situation.  You are denying the 
artisan the tools.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)