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 ---------------------------------------------------------------------- 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
