Re: signum (was: Linear search vs binary)
From: John Gilmore jwgli...@gmail.com Sent: Tuesday, October 22, 2013 9:31 AM PL/I was robbed of FIXEDOVERFLOW for binary fixed values. Use SIZE instead. It is still available for PL/I decimal fixed, i.e., packed decimal values. The LE does in fact make a facility available for executing what is in efffect an arbitrary SPM instruction; but it is documented so poorly---It has been all but hidden---that it is difficult to use. When binary FIXEDOVERFLOW is important I now do the arithmetic in an assembly-language subroutine. Use SIZE instead. SIZE is raised for fixed binary overflow. This a is a pity, a disagreeable consequence of the fact that much PL/I implementation machinery is now shared with C; but it must be conceded that there have been benefits too, e.g., for select groups that are exact functional equivalents of licit C switch statements, which are now better optimized than they once were.
Re: signum (was: Linear search vs binary)
Since the machine architectures that came to mind all have this 3-state result after comparison, I expected the compiler to take advantage of it when I write something like if ( j k ) m = -1; else if (j k) m = 1; else m = 0; return m; A few surprises with gcc, like pretty dumb code without -O3 and then very smart code with -O3 :-) and the result is below. What I considered interesting is that we indeed have a single CR followed by the JL and JNLE so the language allows me to express this situation properly. I suppose the LHI at 062E is also done early to take advantage of the pipeline? (the setting of the scene is with R10 and R2 holding j and k respectively') 8628: 19 a2 cr %r10,%r2 862a: a7 44 00 1a jl 865e main+0x6a 862e: a7 28 00 00 lhi %r2,0 8632: a7 34 00 0b jnle8648 main+0x54 8636: e3 40 f1 10 00 04 lg %r4,272(%r15) 863c: b9 14 00 22 lgfr%r2,%r2 8640: eb af f0 f0 00 04 lmg %r10,%r15,240(%r15) 8646: 07 f4 br %r4 8648: a7 28 00 01 lhi %r2,1 864c: e3 40 f1 10 00 04 lg %r4,272(%r15) 8652: b9 14 00 22 lgfr%r2,%r2 8656: eb af f0 f0 00 04 lmg %r10,%r15,240(%r15) 865c: 07 f4 br %r4 865e: a7 28 ff ff lhi %r2,-1 8662: e3 40 f1 10 00 04 lg %r4,272(%r15) 8668: b9 14 00 22 lgfr%r2,%r2 866c: eb af f0 f0 00 04 lmg %r10,%r15,240(%r15) 8672: 07 f4 br %r4
Re: signum (was: Linear search vs binary)
From: Rob van der Heij rvdh...@gmail.com Sent: Wednesday, October 23, 2013 8:12 PM Since the machine architectures that came to mind all have this 3-state result after comparison, I expected the compiler to take advantage of it when I write something like if ( j k ) m = -1; else if (j k) m = 1; else m = 0; return m; It is sufficient to write: return (sign(j-k) );
Re: signum (was: Linear search vs binary)
Rob, Interestingly, when I take your C example, if ( j k ) m = -1; else if (j k) m = 1; else m = 0; return m; and rewrite it trivially modified in PL/I as if j k then m = -1; else if j k then m = 1; else m = 0; return (m); I cannot reproduce your results. John Gilmore, Ashland, MA 01721 - USA
Re: signum (was: Linear search vs binary)
I understand. I don't even need a computer to do that :-) The return was just to discourage the optimizer to throw away all the code because I didn't use the result. The thing that kept me awake briefly was whether the optimizer would recognize that the shortcut and code a single compare with two branches using the CC. I suppose my next attempt would have been a case statement using sign() Rob On 23 October 2013 12:25, robin robi...@dodo.com.au wrote: From: Rob van der Heij rvdh...@gmail.com Sent: Wednesday, October 23, 2013 8:12 PM Since the machine architectures that came to mind all have this 3-state result after comparison, I expected the compiler to take advantage of it when I write something like if ( j k ) m = -1; else if (j k) m = 1; else m = 0; return m; It is sufficient to write: return (sign(j-k) );
Re: signum (was: Linear search vs binary)
PL/I was robbed of FIXEDOVERFLOW for binary fixed values. It is still available for PL/I decimal fixed, i.e., packed decimal values. The LE does in fact make a facility available for executing what is in efffect an arbitrary SPM instruction; but it is documented so poorly---It has been all but hidden---that it is difficult to use. When binary FIXEDOVERFLOW is important I now do the arithmetic in an assembly-language subroutine. This a is a pity, a disagreeable consequence of the fact that much PL/I implementation machinery is now shared with C; but it must be conceded that there have been benefits too, e.g., for select groups that are exact functional equivalents of licit C switch statements, which are now better optimized than they once were. John Gilmore, Ashland, MA 01721 - USA
