Yes. IBM's going ahead and executing both legs of the conditional branch has always bothered me too. But I guess math units were relatively cheap and it presented a novel way to speed up conditional branches. Shades of quantum computing.
My comment about destroying a was that a was not copied, but ored into a. On Mon, Jul 29, 2019 at 6:42 AM Henry Rich <[email protected]> wrote: > That's a good solution, same idea as Gilles's. As for OR destroying a > register, nowadays all registers are virtual anyway. Intel machines have > 150-odd registers in the execution unit IIRC, even though the > programming model presents only 16 to the programmer. Copying a > register doesn't even take an execution cycle - you just get a virtual > copy of the value you want. > > Yes, I am thinking Intel (if(!(a&&b)) appears 250 times in the JE). > Intel/AMD do not try executing both paths. I think their reasoning is > correct: since the branch predictor usually gets it right, it is better > to put all the processing power on the likely branch rather than being > guaranteed of having to discard half the work. > > Henry Rich > > On 7/29/2019 8:31 AM, Don Guinn wrote: > > First. Since you referred to BXLE I assume you are talking IBM 370 or > > beyond architecture. Unfortunately, I don't know INTEL instructions, but > > your example implies that maybe you are thinking INTEL. > > > > I have a problem with your use of "or" as wouldn't that destroy the > > contents of a? And several people have posted interesting responses there > > seem to be several good solutions. However, below is a solution for IBM > 360. > > > > L 2,A > > M 2,B RESULT IN REGISTER PAIR > > OR 2,3 TO SET CC AS M DOES NOT SET IT > > BNZ AROUND > > ... code > > AROUND EQU * > > > > > > A comment about branch taking a long time. Somewhere in the 1980's the > IBM > > 360 series of machines, whatever it's name was, performed an interesting > > bit of optimization for conditional branch. When a conditional branch > began > > execution both the fall-through and the target of the branch began > > execution. Seems there were two arithmetic units. Once the branch > > determined which path the branch should take, that path of execution was > > used and the other was discarded. Consequently, even though the branch > > itself took a long time it was completely overlapped with the instruction > > execution following the branch. The branch took no time as long as no > other > > conditional branch was encountered. > > > > On Sun, Jul 28, 2019 at 6:51 PM Henry Rich <[email protected]> wrote: > > > >> Many of the members of this Forum will remember the days of assembler > >> language > >> > >> ...and who could less than merry be > >> when writing out BXLE? > >> > >> AND, OR, XOR were our meat. Those days are returning. > >> > >> You have two integer variables a and b and you want to do something if > >> one or both of them are 0. In C, you might write > >> > >> if(a==0 || b==0)stmt; > >> > >> but that will generate the code > >> > >> cmp a,0 > >> bz stmt > >> cmp b,0 > >> bnz notstmt > >> stmt: > >> ... > >> notstmt: > >> > >> Here's the problem: your machine is very slow at branch instructions. > >> Each branch takes 30 times as long as a regular instruction. (I am > >> describing a state-of-the-art Intel CPU when it cannot predict the > >> branches effectively, perhaps because the data is... unpredictable). > >> > >> Obviously, you want to use only one branch instruction. You may use as > >> many arithmetic and logic instructions as you like, but only one > >> branch. The usual condition codes, ZNCV, are available. How tight can > >> you make the code? > >> > >> Example: suppose the problem were to execute stmt if one or both of a > >> and b is NOT zero. Then you would simply write > >> > >> or a,b > >> bnz notstmt > >> ... > >> > >> Checking for zero seems to be harder. > >> > >> No hurry. I have pondered this problem for over a year, and just today > >> I found a solution I consider acceptable. > >> > >> Henry Rich > >> > >> > >> > >> > >> > >> > >> > >> --- > >> This email has been checked for viruses by AVG. > >> https://www.avg.com > >> > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > >> > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
