On 01/09/2010 04:32 PM, Joel C. Ewing wrote: > On 01/09/2010 10:43 AM, Paul Gilmartin wrote: >> On Sat, 9 Jan 2010 09:49:22 -0600, Joel C. Ewing wrote: >>> >>> The case I remember was IBM's SDSF. The intent obviously was an >>> overly-clever attempt to avoid the "overhead" of divides by using >>> multiple TM instructions to test bits in the BCD year, determining leap >>> year by looking for years 0, 4, 8 in even decades and years 2, 6 in odd >>> decades (an algorithm for leap year determination which would first fail >>> in 2100). The code was sufficiently obscure that a bug in the >>> implementation of the algorithm wasn't obvious until it reported 03/01 >>> as 02/29 in a non leap year in the 1990s. I don't know if IBM resolved >>> this by just fixing the code to correctly implement the intended >>> algorithm, or whether they also corrected the algorithm to handle the >>> 100/400 year exceptions. If the former, this may be an example of a >>> class of Y2100 leap-year problems that will surface in 2100 with the >>> crossing of the first yy00 boundary that is not a leap year since the >>> large-scale usage of digital computers. >>> >> This ought to be feasible (correctly) for 1901 to 2099 with two TM >> instructions (and two branches). (Comments?) A third TM and branch >> would handle the 400 year rule. >> >> I wonder, however, whether the extra branches' interrupting the >> pipeline more than offsets the overhead of the divide. (Divide? >> I'd use a multiply and a TM.) CDC Cyber processors were notoriously >> sensitive to pipeline interruptions, and their programmers similarly >> notorious for avoiding branches, even by computing two results and >> combining them with masks. >> >> -- gil > > > Wouldn't it take a fourth TM (or a CLI) to get the 100-year rule in as > well? Or is there a more subtle way than: > > TM X'01',YY > BNZ NOT_LEAP Branch if odd > TM X'12',YY > BM NOT_LEAP Branch if 02, 06, 10, 14, 18 > * Here if 00, 04, 08, 12, 16 > CLI YY,X'00' > BNZ LEAP div by 4, not multiple of 100 > TM X'03',CC > BNZ NOT_LEAP div by 100 but not 400 > LEAP DS 0H > ... > NOT_LEAP DS 0H > ... > At least I think the above works... It isn't at all obvious without > checking through all the possible combinations. Caught my own mistake. The test for CC divisible by four obviously requires the same sort of sensitivity to even/odd millenia as the tests for even/odd decades in the checks for YY divisible by four. The logic is so much more likely to be right if one sticks to the original "divisible by" definition and avoids bit twiddding.
-- Joel C. Ewing, Fort Smith, AR jremoveccapsew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
