I agree, doing it manually is a reasonable option, though even that gets a little more complicated if you're in BCD mode.
On Thu, Aug 20, 2009 at 12:32 PM, nathan binkert<[email protected]> wrote: > I have a couple of comments on this changeset. First, I think this > has the potential to affect alpha, so you should run regressions. > (MC146818 is used by alpha for the clock). > > An alternative it to just increment the fields and add rollover code. > It would a bunch of lines of code, but really easy and obviously > correct. The only somewhat complicated code would be rolling over the > month, but of course, that's not very difficult. In some ways, I think > this would be preferred because the timezone code lead to hidden > differences on platforms of stuff like leap seconds. I think we want > to say that every day has 86400 seconds. Period. no surprises. I > don't think we necessarily care about supporting a rollover at a year, > but I don't know what other complicated stuff might exist in the > timezone code and I'd rather not have to worry about it. > > Nate > > On Thu, Aug 20, 2009 at 9:50 AM, Steve Reinhardt<[email protected]> wrote: >> Hi Gabe, >> >> I'm probably missing something here, but all the mucking about with TZ >> caught my attention as something that would be nice to avoid. >> Wouldn't it work to keep curTime as a time_t and just increment it on >> every tick event, then call setTime(*gmtime(&curTime)) only when >> you're about to touch clock_data in readData() or writeData()? >> >> In fact, you could get rid of the union altogether as a member (but >> keep the type) and just create a local instance on each call to >> readData() or writeData() that's dynamically populated from the time_t >> curTime. (OK, on closer inspection that's not quite so clean since >> you do need to store the *_alrm fields separately. So it probably is >> easier just to keep the member, but treat all the fields other than >> *_alrm as temporaries.) >> >> I think you're also missing the step of updating curTime if clock_data >> is changed in writeData(), independent of whether curTime is a struct >> tm or a time_t. >> >> BTW, I wanted to congratulate you on all the recent x86 progress,,, >> this is looking awesome. I take it you're fixing the RTC because >> you're now getting far enough to notice that it's not advancing? >> >> Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
