changeset ade9a088bb14 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=ade9a088bb14
description:
X86: Make the real time clock actually keep track of time.
diffstat:
2 files changed, 103 insertions(+), 19 deletions(-)
src/dev/mc146818.cc | 96
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
On Thu, Aug 20, 2009 at 10:31 AM, Gabriel Michael
Blackgbl...@eecs.umich.edu wrote:
Quoting Steve Reinhardt ste...@gmail.com:
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
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
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 binkertn...@binkert.org wrote:
I have a couple of comments on this changeset. First, I think this
has the potential to affect
On Thu, Aug 20, 2009 at 12:58 PM, nathan binkertn...@binkert.org wrote:
I agree, doing it manually is a reasonable option, though even that
gets a little more complicated if you're in BCD mode.
Sure, but he's already got a bcdize function. Could always write an
unbcdize function. Actually,
Quoting nathan binkert n...@binkert.org:
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).
That's right, and I did that before I committed. I was a little
On Thu, Aug 20, 2009 at 2:38 PM, nathan binkertn...@binkert.org wrote:
I'll comment on the rest of this discussion once I've had a chance to
read through it and think about it. My immediate thought is that while
a simplified manual roll over sort of mechanism would avoid using the
library
If it's all UTC then there's no daylight savings issue. Plus given
the rate at which we simulate, we'd have to have a very poorly chosen
starting time date to simulate across a leap second (from
http://en.wikipedia.org/wiki/Leap_second:
Leap seconds occur only at the end of a UTC month, and
Quoting nathan binkert n...@binkert.org:
If it's all UTC then there's no daylight savings issue. Plus given
the rate at which we simulate, we'd have to have a very poorly chosen
starting time date to simulate across a leap second (from
http://en.wikipedia.org/wiki/Leap_second:
Leap seconds
10 matches
Mail list logo
