Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@dual.crhc.uiuc.edu (Andy Glew) Newsgroups: comp.arch Subject: Re: 64 bit clocks Message-ID: Date: 23 Aug 90 17:11:08 GMT References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <26012@bellcore.bellcore.com> <11187@alice.UUCP> <1990Aug23.022416.14798@sco.COM> <26196@bellcore.bellcore.com> Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois, Computer Systems Group Lines: 23 In-Reply-To: mo@messy.bellcore.com's message of 23 Aug 90 14:13:01 GMT As I have noted in several previous postings, I have seen hardware designs where large (64 bit timers) could not be provided, because the timer could not increment within the clock cycle of the machine (without an expensive carry lookahead network). I suggested providing the time in carry-save format, and letting software postprocess such a timestamp if desired. It should be obvious that a normal binary encoding and the carry save encoding of the time can be combined. Eg. build a cheap ripple timer with a large number of bits (say 61 bits). If the greatest length that a ripple can complete in a machine cycle is 16 bits, latch the carries at the 16th, 32nd, and 48th bit position. Conveniently, those three bits can fit in the lower part of a 64 bit word returned. You can use this directly as a timestamp; true time is obtained as true_time = (timestamp >> 3) + ((timestamp&1)<<16) + ((timestamp&2)<<(32-1)) + ((timestamp&4)<<(48-2)) -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]