On Tue, Sep 15, 2009 at 5:07 AM, Gabe Black wrote:
>
> That would work, except that you'd have to punch a readCR3 function
> through all the *context classes and CPU classes between the producer
> and consumer of that value. With templates, that all still happens, but
> it's anonymous and doesn't
changeset 8c68656b8564 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8c68656b8564
description:
Add an I/O cache to FS config even if there's just an "L2" cache.
diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
configs/example/fs.py |2 +-
diffs (12 lines):
On Tue, Aug 25, 2009 at 7:07 PM, Steve Reinhardt wrote:
> On Tue, Aug 25, 2009 at 6:56 PM, Gabriel Michael
> Black wrote:
>>
>>> Probably the easiest way would just be to take a current decoder.cc,
>>> hack it up manually to match one of the thigns we're proposi
On Wed, Sep 9, 2009 at 10:47 AM, Gabriel Michael Black
wrote:
> As far as how often those functions are called, the read one will be called
> fairly often for address translation, and potentially in the predecoder
> depending on the ISA. The writing one is likely called substantially less
> often.
I'll just throw in a plug for Nate's cprintf() library here... it
doesn't have these issues.
Steve
On Fri, Sep 11, 2009 at 8:58 AM, wrote:
> changeset 5437a0eeb822 in /z/repo/m5
> details: http://repo.m5sim.org/m5?cmd=changeset;node=5437a0eeb822
> description:
> Object print bug fix
>
>
I had similar thoughts... I think Gabe's idea could work, but I'm not
sold on the motivation. If it's just for performance, do we know for
sure that this is actually a performance bottleneck?
Also, I don't think we can get rid of the MiscReg space and the
indices, since they're needed to indicate
to that config_as_param patch, I'm
interested in knowing more about how the Ruby config file gets
specified currently (i.e., I don't really understand the problem that
patch is trying to fix).
Steve
On Fri, Sep 4, 2009 at 12:25 PM, Steve Reinhardt wrote:
> Another question I have i
wrong?
>
> Actually, I sent my last email only to you because I thought that it would
> be more efficient to work out the details with you without flooding
> everybody's mailboxes. However, please let me know if you would rather have
> me post this on m5-dev.
>
> regards,
>
hat way, all the
> changes to test dma requests will be just in the tester.
>
> But, if I understand correctly, you are more concerned with having DMA
> separate. Not just in the tester, but in general. Because DMA was made into
> it's own object in the coherence protocol, I don&
I think you've got the basic idea right... in terms of renaming the stats:
- "find | perl -pie 's///;' " is really handy for
this kind of thing.
- Even with the name substitution, the order still won't be right, so
you'll either have to use tests/diff-out (my recommendation) or sort
the files bef
On Tue, Sep 1, 2009 at 1:52 PM, Gabriel Michael
Black wrote:
>> So, in SE mode, is there a distinction made between two threads (workloads)
>> belonging to the same process and two threads belonging to different
>> processes? In other words, if I were to spawn two threads from a single
>> program,
On Tue, Sep 1, 2009 at 9:09 AM, Derek Hower wrote:
> On Tue, Sep 1, 2009 at 10:29 AM, Steve Reinhardt wrote:
>> Before we worry about the details of this patch, I have a higher-level
>> question: why do we need a separate DMA request type and port at all?
>> On the M5 side,
made
these modifications already, but it should avoid needing any changes
at all to the packet or request classes or to memtester.cc, I think.
Steve
On Tue, Sep 1, 2009 at 8:52 AM, Polina Dudnik wrote:
>
>
> On Tue, Sep 1, 2009 at 10:29 AM, Steve Reinhardt wrote:
>>
>> Befo
_group instead of exit. This behavior is different for the "hello"
> binary distributed with M5 because it does NOT make a syscall to exit_group
> but makes a call to exit.
>
> regards,
> Soumyaroop.
>
> On Tue, Sep 1, 2009 at 11:39 AM, Steve Reinhardt wrote:
>>
What exactly is the problem that you're encountering?
Note that syscall emulation only occurs in SE mode (that's what the SE
stands for). The file syscall_emul.cc doesn't even get compiled if
FULL_SYSTEM is defined.
Steve
On Mon, Aug 31, 2009 at 1:20 PM, soumyaroop roy wrote:
> Hello evebody,
>
BTW, if you use the '-e' or '-m' options to qnew or qref you can
enter/edit a commit message for a patch which will get used when you
actually commit... obviously preferable to the default of '[mq]:
patch_name'. It's easy to overlook, I know... I've done this a few
times myself.
Steve
On Tue, S
Before we worry about the details of this patch, I have a higher-level
question: why do we need a separate DMA request type and port at all?
On the M5 side, we've gotten by just fine so far with ReadReq and
WriteReq, and M5 devices don't explicitly mark their DMA requests as
such. I understand tha
and
DmaPort::dmaAction() in dev/io_device.cc for a couple of examples.
Steve
>
> Thanks,
>
> Polina
>
> On Mon, Aug 31, 2009 at 6:16 PM, Steve Reinhardt wrote:
>>
>> Good question. Looks like historical cruft to me. I think there used
>> to be a mode that t
Good question. Looks like historical cruft to me. I think there used
to be a mode that tested variable-size accesses but that mode got
ripped out. Note that access_size is log2 of the access size, so
setting it to 0 means byte accesses.
Steve
On Mon, Aug 31, 2009 at 3:30 PM, Polina Dudnik wrot
I'm rerunning regressions on zizzer and everything seems fine so
far... this looks like an issue with swig on the pool machines. Does
anyone have any idea why things might have changed (either with the
version of swig on the pool machines, or the version that we require)?
Unfortunately the log do
conds-per-tick value; see getrusageFunc() and getElapsedTime()
in syscall_emul.hh.
BTW, the recommended way to send out patches like this is to use the
mercurial patchbomb extension:
http://mercurial.selenic.com/wiki/PatchbombExtension.
Steve
On Fri, Aug 28, 2009 at 6:41 AM, Steve Reinhardt wrote:
>
Wow, this is a nice surprise! Thanks!
I'll try and take a look at the code and give you feedback, but it
might not be right away.
BTW, you might find this interesting:
http://www.m5sim.org/flyspray/task/18. It's actually been on our "to
do" list even longer... I think the date is just when we s
On Wed, Aug 26, 2009 at 12:57 PM, Gabe Black wrote:
>> 1. Get StaticInst for PC X (if any).
>> 2. Read the StaticInst's ExtMachInst to learn that the original
>> instruction it represents occupied N bytes, and what those bytes were.
>> 3. Compare the N bytes in memory at PC X with the N bytes store
On Tue, Aug 25, 2009 at 11:03 PM, Gabe Black wrote:
>
> The problem is that you need the displacement/immediate to actually do
> the cache look up since those are part of the ExtMachInst and are
> factored into a match. Those could be ignored for a preliminary lookup,
> read in if there's a match,
(Getting this back on the list again...)
On Tue, Aug 25, 2009 at 10:32 PM, Gabe Black wrote:
> Steve Reinhardt wrote:
>> On Tue, Aug 25, 2009 at 9:46 PM, Gabe Black wrote:
>>
>>> Steve Reinhardt wrote:
>>>
>>>> On Tue, Aug 25, 2009
On Tue, Aug 25, 2009 at 6:56 PM, Gabriel Michael
Black wrote:
>
> The decode cache is being used. The cache is keyed on ExtMachInsts, and x86
> translates the stream of instruction bytes into those before they hit the
> decoder. X86 defines those as a structure that holds all the relevant
> informa
On Tue, Aug 25, 2009 at 6:30 PM, Gabriel Michael
Black wrote:
>>
>> Actually I was hoping that you wouldn't have to include all the .hh
>> files. If the main decoder in main_decoder.cc calls out to a
>> subdecoder for x87 ops in x87_decoder.cc, then a header that declares
>> the instruction object
On Tue, Aug 25, 2009 at 1:59 PM, Gabriel Michael
Black wrote:
> Quoting Steve Reinhardt :
>> - Pass by reference operands should also just be flagged as errors,
>> since there's no way to know if the operand is read, written, or both.
>
> It's more difficult th
es)
> - current system is just too much of pain or too slow?
>
> Sorry if I'm forcing redundancy on anyone with the questions ... Just trying
> to get a clear picture of the what/why/how going on in my head...
>
> On Tue, Aug 25, 2009 at 2:59 PM, Steve Reinhardt wrote:
>&
(Splitting this off-list thread into a third part.)
On Mon, Aug 24, 2009 at 12:39 AM, Gabe Black wrote:
> Steve Reinhardt wrote:
>> On Sun, Aug 23, 2009 at 11:21 PM, Gabe Black wrote:
>>> Along those lines, something I've considered for quite a while, tried
>>&g
(Redirecting this one to m5-dev too. To keep these threads more
manageable I'm just responding to the parts related to the original
topic of splitting up decoder.cc.)
On Mon, Aug 24, 2009 at 12:39 AM, Gabe Black wrote:
> Steve Reinhardt wrote:
>>
>> My thought was
>>
(Is there a reason we're not having this conversation on m5-dev? I
moved it back there for posterity, and in case anyone else wants to
chime in. Note that we're discussing better processing of the C++
code snippets in the ISA description language.)
On Tue, Aug 25, 2009 at 1:08 AM, Gabe Black wro
On Thu, Aug 20, 2009 at 2:38 PM, nathan binkert 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 functions and
On Thu, Aug 20, 2009 at 12:58 PM, nathan binkert 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, what probabl
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 Rein
On Thu, Aug 20, 2009 at 10:31 AM, Gabriel Michael
Black wrote:
> Quoting Steve Reinhardt :
>> 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 cl
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
ile unconditional could easily solve your problem.
Steve
On Tue, Aug 18, 2009 at 10:53 AM, Steve Reinhardt wrote:
> Actually the "default=ALPHA_SE" in Somayeh's specific command line
> should be a complete no-op. All "default=FOO build/BAR/*" does is
> that if t
Actually the "default=ALPHA_SE" in Somayeh's specific command line
should be a complete no-op. All "default=FOO build/BAR/*" does is
that if there are no existing variable settings in build/variables/BAR
(from a previous build) then the initial settings are read out of
build_opts/FOO instead of bu
The reason you don't get the error with m5.fast is because m5.fast
compiles out assertions. The issue is still there. (In general I
like to run regressions with m5.opt rather than m5.fast for this
reason.)
Using gdb is easy if you run m5 directly and not via the scons
regression framework (which
to be done with this variables file?
>
> -Derek
>
> On Tue, Aug 4, 2009 at 4:03 PM, Steve Reinhardt wrote:
>> On Tue, Aug 4, 2009 at 1:33 PM, nathan binkert wrote:
>>>> Now that the other GEM5 issues are mostly resolved (thanks everyone!), I
>>>> wanted to
On Tue, Aug 4, 2009 at 1:33 PM, nathan binkert wrote:
>> Now that the other GEM5 issues are mostly resolved (thanks everyone!), I
>> wanted to discuss the protocol directory issue in more detail. I'm
>> completely fine with recompiling all files when changing protocols. I would
>> just like th
On Mon, Aug 3, 2009 at 2:38 PM, Derek Hower wrote:
>
> I see. Unfortunately this isn't possible at the moment. In the new
> configuration, there really isn't any notion of "local" because there
> is no longer a generated chip object. Now Ruby (network included)
> doesn't care where a controller
On Mon, Aug 3, 2009 at 11:16 AM, Derek Hower wrote:
>
> I do like the idea of a generic SequencerMsg class, but am a little
> worried that it would ultimately be confusing. We can certianly split
> DMARequestMsg into two different types, one for the request to the DMA
> sequencer and one for the r
On Sun, Aug 2, 2009 at 1:17 PM, nathan binkert wrote:
>> Also, I think with this flag in place we ought to be able to get rid
>> of the tlb_mode setting; the TLB can just look and see whether
>> isInstFetch() is true to decide how to handle the request... does
>> anyone agree or disagree?
>
> Well,
x27;m going
> to go ahead and add this standard to the style guide. ok?
>
> Nate
>
> On Sat, Aug 1, 2009 at 10:51 PM, Steve Reinhardt
> wrote:
>> changeset 50125d42559c in /z/repo/m5
>> details: http://repo.m5sim.org/m5?cmd=changeset;node=50125d42559c
>>
f the tlb_mode setting; the TLB can just look and see whether
isInstFetch() is true to decide how to handle the request... does
anyone agree or disagree?
Steve
On Sat, Aug 1, 2009 at 10:51 PM, Steve Reinhardt wrote:
> changeset 7ed8937e375a in /z/repo/m5
> details: http://repo.m5sim.org/m5?cmd=cha
changeset 7ed8937e375a in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=7ed8937e375a
description:
Fix setting of INST_FETCH flag for O3 CPU.
It's still broken in inorder.
Also enhance DPRINTFs in cache and physical memory so we
can see more easily w
changeset 50125d42559c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=50125d42559c
description:
Rename internal Request fields to start with '_'.
The inconsistency was causing a subtle bug with some of the
constructors where the params had the same name a
changeset 9e35cdc95e81 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9e35cdc95e81
description:
Clean up some inconsistencies with Request flags.
diffstat:
4 files changed, 11 insertions(+), 20 deletions(-)
src/arch/arm/tlb.cc |2 +-
src/arch/sparc/tlb.cc |2 +
On Fri, Jul 24, 2009 at 10:23 PM, Gabe Black wrote:
>
> We could also add a command line argument to the script. One thing to
> note is that I think se.py is supposed to just be an example. I have the
> impression it's often used exactly as is though, so that may not be a
> valid way to look at it.
I'm not sure exactly what you're asking... you should instantiate
Debug from your configuration script. Once you do that, everything
else should just work.
I don't know enough about how lib-ruby is built or used to say more.
Steve
On Wed, Jul 22, 2009 at 1:33 PM, Somayeh Sardashti wrote:
> Hi,
FYI, the update_ref=True flag is unnecessary for the initial build.
It causes the reference outputs for any regression tests you run to be
updated based on the latest outputs, but since you're not running any
tests it's basically a no-op.
Steve
On Thu, Jul 23, 2009 at 12:27 PM, Somayeh Sardashti
On Tue, Jul 21, 2009 at 10:55 AM, Derek Hower wrote:
>>
>>> 2) What's the best way to add multiple protocols to the regression
>>> tests, so that all ruby related tests are run for each protocol?
>>> Somayeh is almost done with MESI and we need to make sure it's tested.
>> I don't have a mechanism
I can't reproduce them either. It's a little hard to grok the
regression output since the compile is farmed out to our simulation
pool, but there are error messages complaining about not finding files
that clearly exist in the repo, so my suspicion is that it's a symptom
of NFS problems on our poo
g/os/project/opengrok/ has some information
>>> about
>>> it. That says it's integrated with mercurial and "can understand
>>> various
>>> program file formats" which may include python.
>>>
>>> Gabe
>>>
>>> Stev
Yes.
On Mon, Jul 20, 2009 at 5:46 PM, Lisa Hsu wrote:
> anyone get this?
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>
>
___
m5-dev mailing list
m5-dev@m5sim.org
ht
Hi Derek,
Has Nate mentioned his cprintf package to you? It's basically a
type-safe C++ printf, which most of us find much nicer than C++ stream
I/O, particularly if you have to do a lot of formatting. I don't
consider it a major integration issue (like integrating statistics or
debugging), but
Are you sure it's not you? I saw both patches and the third manual
email, and also replied (to the list) to your third email telling you
that I'd seen the first two.
Steve
On Sat, Jul 18, 2009 at 11:27 AM, Gabe Black wrote:
> I've tried sending a patch to this list three times, twice with hg
There's no real control over ordering... I believe init() is called on
objects in the same order that they were constructed, but you don't have a
lot of control over the construction order (short of the fact that if B is a
parameter to A then B will be constructed first) and it's probably best not
The /z/m5 directory is on an internal U-M machine (zizzer), though the
regressions themselves are typically run on the Michigan simulation pool.
For this particular case, that shouldn't matter though; you should get the
same failure when you run the same test on a clean repository. If not, then
th
On Thu, Jul 9, 2009 at 1:24 PM, nathan binkert wrote:
> > - You're guaranteed that any SimObject that is passed to you as a
> parameter
> > has been constructed before your constructor is called, so that the
> pointer
> > in the params struct is valid. Since init() hasn't been called yet you
> >
ch
> is called exactly after constructing the object. However , sometimes order
> of defining and initiating different objects are important for us, so we
> should handle them too.
>
> Somayeh
>
>
> Steve Reinhardt wrote:
>
>> Hi Somayeh,
>>
>>
I'm sorta just dreaming here, but I'm getting used to occasionally browsing
the code through repo.m5sim.org, and it would be really nice if:
1. We had a web-based cross-reference (like lxr), so I don't have to switch
from firefox to an ssh session running cscope.
2a. Better yet, if there was a way
What we really need for x86 is more general locking. We've added a LOCKED
flag to the mem request, and the current x86 microcode uses this for locked
operations, where the semantics are that a load with the LOCKED flag (which
should "lock" the cache block) is always followed by a store with the LO
changeset a37f8971b271 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a37f8971b271
description:
Add ability to skip tests by adding 'skip' file to test dir,
and skip simple-timing-mp-ruby test for now (until we fix ruby atomics).
diffstat:
2 files changed, 3 in
Do we even use make_release.py any more? I'd think not since we're not
doing official releases. I noticed it the other day and was wondering if we
should just delete it.
On a separate but related note, we should update m5-stable at some point;
it's getting ridiculously out of date.
Steve
On Tu
On Tue, Jun 30, 2009 at 3:24 PM, Gabriel Michael Black <
gbl...@eecs.umich.edu> wrote:
> This is fine, except it doesn't really address the op_rd and op_wb
> issue, ie. having different code to read and write the register
> arguments in the execute method. I'd like to have that fixed as soon
> sin
On Tue, Jun 30, 2009 at 2:14 AM, Jack Whitham wrote:
> > I've only been half-following this thread, but I believe Gabe is right:
> you
> > need StaticInst objects that claim to be different things
> > (branch/non-branch, conditional/unconditional, dependent/independent of
> > flags, etc.) based on
On Mon, Jun 29, 2009 at 7:07 PM, Gabriel Michael Black <
gbl...@eecs.umich.edu> wrote:
> Quoting Steve Reinhardt :
>
> > On Mon, Jun 29, 2009 at 6:02 PM, Gabriel Michael Black <
> > gbl...@eecs.umich.edu> wrote:
> >
> >> That is true, but I t
On Mon, Jun 29, 2009 at 6:02 PM, Gabriel Michael Black <
gbl...@eecs.umich.edu> wrote:
> That is true, but I think what he's talking about is when the CPSR
> doesn't actually matter at all since the condition is "always". I
> don't know what the best way to do that would be, but one possibility
>
Sorry for the slow reply... I'm traveling this week.
On Sun, Jun 21, 2009 at 10:30 AM, Gabe Black wrote:
> To differentiate between branch/no branch that's actually along the
> lines of what I want to do, which in retrospect doesn't really have
> anything to do with what I was talking about here
Have you looked at how the Alpha ISA detects writes to R31 to generate
no-ops instead of regular instructions? Is there any reason that approach
(or a similar one) wouldn't work? You may not want two completely different
instructions like Alpha, but you could do the comparison with R15 in the
sam
Within a real core, there's a lot of linkage between speculation, store/load
forwarding, memory disambiguation, enforcing consistency models, etc. such
that the load and store queues are tightly linked. Mostly this has to do
with out-of-order speculative execution. If you are only buffering
commi
I don't think devices do anything on functional accesses; you probably want
an atomic access. That shouldn't be a problem as long as the memory system
is not in timing mode. Is this just for kvm initialization or does it occur
during normal operation?
Is it possible just to make the access just
This looks like a pool glitch... there's no additional error info from qdo
(didn't we used to get more?) and I can't reproduce it.
Steve
On Sat, May 30, 2009 at 12:19 AM, Cron Daemon wrote:
> scons: *** [build/ALPHA_FS/base/loader/object_file.fo] Error 1
> * build/ALPHA_SE/tests/fast/quick/3
changeset 0145a40f6b27 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=0145a40f6b27
description:
util: mkblankimage.sh should be executable
diffstat:
0 files changed
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/ma
changeset 02e6dd8b281a in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=02e6dd8b281a
description:
igbe: Fix descriptor cache bug.
diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
src/dev/i8254xGBe.hh |2 +-
diffs (12 lines):
diff -r 2f4020838149 -r 02e6dd8b28
Does anyone know why m5 doesn't die when its stdout is closed? When
tracediff gives up, instead of the two m5 jobs dying, they just keep going
until you kill them explicitly. A typical program would die immediately on
the SIGPIPE.
You can verify this behavior by running m5 with tracing on and pi
On Wed, May 20, 2009 at 7:22 AM, Korey Sewell wrote:
> Otherwise, we'd have to figure out to not build InOrder for FS but
> build it for SE.
>
That should be relatively easy. Right now it looks like
build_opts/ALPHA_FS is the only config that doesn't have an explicit setting
for CPU_MODELS, so
Looks like the EIO files failed to build because of stale references to
sim/host.hh, and the inorder compiles failed with a variety of errors (no
matching function, no declaration for X, etc.) like there's a missing header
file or something.
Steve
On Wed, May 20, 2009 at 3:25 AM, Cron Daemon wrot
When the script went to clean out the directory to do the scratch rebuild on
Saturday night the 'rm -rf' failed due to a permissions problem, which
aborted the script before the hg clone occurred. Subsequent runs failed
since there was no repo in place as they expected.
I hacked in a RUBY=True fl
Note that the Alpha inorder-timing test passed... I'm guessing that whatever
Korey did to get it going he did only to ALPHA_SE and not to MIPS_SE.
Tonight is the weekly "rebuild everything from scratch" regression so
there's no point in trying to fix it now, it should take care of itself.
Steve
O
This all sounds great to me. I was never particularly fond of the host.hh
name either.
Steve
On Fri, May 15, 2009 at 11:34 AM, nathan binkert wrote:
> I recently ran into a bug that would have been caught by the compiler
> if we didn't have -Wno-sign-compare in our build. I've made attempts
I think I know what the problem is... to reset the build variables for
ALPHA_SE, you don't need to delete build/ALPHA_SE, you need to delete
build/variables/ALPHA_SE. Korey, if you delete that file then it should be
OK.
Steve
On Fri, May 15, 2009 at 12:24 AM, Cron Daemon wrote:
> ['g++', '-o',
On Thu, May 14, 2009 at 5:46 PM, Korey Sewell wrote:
> Two things:
> 1) I see that there is an instruction flag in the Request Objects
> called "INST_FETCH" but I didnt see anywhere in the code where this is
> being utilized... Are there plans to use this information for maybe
> like cache replac
at 1:19 PM, Korey Sewell wrote:
> That makes senseJust to be clear, I should delete the
> build/ALPHA_SE and rebuild it. Then, *hopefully* the regressions will
> run with no hiccups.
>
> On Wed, May 13, 2009 at 3:05 PM, Steve Reinhardt wrote:
> > You probably need to delete
s default?
>
> On Wed, May 13, 2009 at 12:29 PM, nathan binkert wrote:
> > He does have sudo access, but that's not the right directory.
> >
> > Look in: /z/m5/regression/zizzer/m5/build
> >
> > On Wed, May 13, 2009 at 8:07 AM, Korey Sewell wrote:
> >&
Don't you have sudo access on zizzer?
On Wed, May 13, 2009 at 8:07 AM, Korey Sewell wrote:
> > On Wed, May 13, 2009 at 9:32 AM, Steve Reinhardt
> wrote:
> > zizzer (note the sender's email address)
>
> I'm having a little trouble figuring out this error...
zizzer (note the sender's email address)
On Wed, May 13, 2009 at 6:08 AM, Korey Sewell wrote:
> > See /z/m5/regression/regress-2009-05-13-03:00:01 for details.
> Wher can I find this regression output message?
>
> daystrom?
> poolfs?
>
>
>
> --
> - Korey
> __
changeset 8b240f106634 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8b240f106634
description:
ruby: Initial references for ruby regressions
diffstat:
63 files changed, 12397 insertions(+)
tests/quick/00.hello/ref/alpha/linux/simple-atomic-ruby/config.ini
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+# Authors:
changeset 29b7b7aba911 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=29b7b7aba911
description:
ruby: Check stderr and not stdin before hanging on an assert.
diffstat:
2 files changed, 3 insertions(+), 3 deletions(-)
src/mem/ruby/common/Debug.hh |4 ++--
src/mem/sl
Yea, in the default hierarchical snoop-based model there's only one modified
copy at a time. If the L2 knows that an L1 has a modified copy then it
should not respond. If that's not known for sure from the coherence state
whether the L1 or L2 should respond then that is problematic.
Steve
On Tu
I actually looked at the code a bit this time; and I have a hypothesis that
the problem arises from two similar but fundamentally different models of
"bypassing" potential event-based delays:
main() {
x_will_callback = x();
if (!x_will_callback) y();
}
x() {
if (...) { sched_callback(
On Sun, May 3, 2009 at 12:09 AM, Gabe Black wrote:
> While this does avoid the segfault, it also causes some other bug which
> crashes just about any of the simple timing regressions. I hadn't
> actually tried any of the quick regressions when I sent that out since
> my other testing had tricked
You're right that the simple timing CPU is basically driven forward by the
responses to ifetch requests. The original idea (that I don't think has
changed) is to be the simplest, basically functional-only CPU that you can
have that is capable of driving the memory system in timing mode. So having
Superficially it looks good to me though; thanks for doing this.
I'm a little squeamish about it scheduling the event right at curTick;
there's just something "not right" about that. However, I definitely prefer
that to the even more meaningless and arbitrary "curTick+1". Probably the
"right" th
On Thu, Apr 30, 2009 at 2:54 PM, Korey Sewell wrote:
> > Actually it does because -all- floating point registers are then 32 bits.
> > The existence of 64 bit registers is just an illusion the instructions
> > provide by gluing two 32 bit registers together internally.
> I understand that for MIP
I don't think I can respond to every point in this discussion, but here are
my general thoughts:
- Though they look superficially similar, the SPARC/MIPS single/double FP
accesses shouldn't necessarily be handled the same way as x86
partial-register writes. They're both awkward and ugly, but ther
801 - 900 of 1287 matches
Mail list logo
