* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
*
changeset 2cd3ce4fa03f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=2cd3ce4fa03f
description:
X86: Add microassembler symbols for floating point stack register
operands.
diffstat:
1 file changed, 2 insertions(+)
src/arch/x86/isa/microasm.isa |2 ++
diffs (12
changeset 6d3645f68654 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6d3645f68654
description:
X86: Don't insist on binary encoding for the RTC since we implement BCD.
diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
src/dev/mc146818.cc |2 +-
diffs (12
changeset de112a8ac3d8 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=de112a8ac3d8
description:
X86: Fix the decoding for and fill out FST and FSTP.
diffstat:
2 files changed, 10 insertions(+), 2 deletions(-)
src/arch/x86/isa/decoder/x87.isa
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
Hello everybody,
I was able to zero in on a couple of places in 'thread_state.hh' of the
inorder code where the thread id was hardcoded with a '0'. The following
changes makes the 01.hello.2t.smt work correctly in inorder now.
diff --git a/src/cpu/inorder/thread_state.hh
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
Yea, I'm working with Soymayaroop on it
I'll make sure whatever patches are made get in the tree...
On Thu, Aug 20, 2009 at 4:06 PM, nathan binkert n...@binkert.org wrote:
Korey,
Will you take responsibility for integrating Soymayaroop's Changes?
Thanks,
Nate
On Thu, Aug 20, 2009
16 matches
Mail list logo
