bit of effort into allowing multiple
> protocols to be compiled into the same binary. That would really fix
> the problem, right?
>
> Nate
>
> On Mon, Feb 1, 2010 at 8:46 AM, Steve Reinhardt wrote:
>> OK, I realize the idea I was originally thinking of didn't solve
tests (that
really don't require a cache hierarchy at all) on all of the different
ruby protocol builds, but I don't think any of those are very long, so
that shouldn't be so bad to put up with.
Steve
On Sun, Jan 31, 2010 at 10:53 PM, Steve Reinhardt wrote:
> I'm not sure i
gt; From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
> Steve Reinhardt
> Sent: Sunday, January 31, 2010 4:40 PM
> To: M5 Developer List
> Subject: Re: [m5-dev] Cron
> /z/m5/regression/do-regression--scratch all
>
> OK, I believe it's a problem Brad
otocol to not find any applicable configurations since
tests/SConscript is looking for a different default protocol.
I think the best way to fix this is to forget trying to have the test
configs track the 'default' Ruby protocol, but instead to always have
the protocol explicit in the conf
I'm looking at it now... I'm not sure exactly what the error is, but
it looks like it's running *only* the ruby tests now, and acting like
the non-ruby tests don't exist.
Steve
On Sun, Jan 31, 2010 at 11:24 AM, Beckmann, Brad wrote:
> I agree, I don't think it is working correctly. I don't have
changeset 341a71fd2600 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=341a71fd2600
description:
Garnet: reorganize directory tree.
Rename the ruby/network/garnet-foo directories to garnet/foo.
Move the common NetworkHeader.hh file from garnet-fixed-pipeli
changeset a9e3c07205a8 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a9e3c07205a8
description:
ruby: Calculate system total memory capacity in Python
rather than in RubySystem object.
diffstat:
3 files changed, 12 insertions(+), 13 deletions(-)
configs/example
changeset c07cf29b5a33 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c07cf29b5a33
description:
ruby: Add support for generating topologies in Python.
diffstat:
7 files changed, 140 insertions(+), 148 deletions(-)
configs/example/memtest-ruby.py
changeset c3a3c09af8be in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c3a3c09af8be
description:
scons: ignore blank lines in .slicc files
diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
src/mem/protocol/SConscript |2 +-
diffs (12 lines):
diff -r 2a1a3d916
changeset a658c315512c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a658c315512c
description:
ruby: Convert most Ruby objects to M5 SimObjects.
The necessary companion conversion of Ruby objects generated by SLICC
are converted to M5 SimObjects in the f
changeset 2a1a3d916ca8 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=2a1a3d916ca8
description:
ruby: Make SLICC-generated objects SimObjects.
Also add SLICC support for state-machine parameter defaults
(passed through to Python as SimObject Param default
changeset 22df98a968bf in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=22df98a968bf
description:
tests: added M5_TEST_PROGS environment variable
to allow override of global location for regression test binaries.
diffstat:
1 file changed, 2 insertions(+), 3 delet
changeset 5eb6e323b595 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=5eb6e323b595
description:
ruby: get rid of obsolete, unused CustomTopology class.
diffstat:
3 files changed, 158 deletions(-)
src/mem/ruby/network/simple/CustomTopology.cc | 140
On Tue, Jan 26, 2010 at 2:10 PM, nathan binkert wrote:
>> Has anyone used the BATCH_CMD facility in our SConstruct to run
>> compiles or regressions using LSF? If so, any patches you can share?
>
> I am very interested as well. I looked into this at one point and
> Gabe may have as well while he
Has anyone used the BATCH_CMD facility in our SConstruct to run
compiles or regressions using LSF? If so, any patches you can share?
Thanks,
Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
See the calls to translateAtomic() in cpu/base_dyn_inst.hh.
Steve
On Wed, Jan 20, 2010 at 9:32 AM, Yuval Peress wrote:
> Hello,
>
> I am working on caches in M5's full system simulation using the o3 cpu.
> While working on the vport class (mem/vport.hh), I noticed a call to
> TheISA::vtophys(...
It looks like there are some unrelated changes to a couple of
config/*.rb files mixed in here... they ought to be in a separate
patch.
Steve
On Tue, Jan 19, 2010 at 3:20 PM, Derek Hower wrote:
> # HG changeset patch
> # User Derek Hower
> # Date 1263942696 21600
> # Node ID 21fbf0412e0d63246d10
As Brad already pointed out, it'd be better just to go back where this
code was commented out and remove it there. You ought to be able to
qfold this patch into the earlier one to achieve that.
Steve
On Tue, Jan 19, 2010 at 3:20 PM, Derek Hower wrote:
> # HG changeset patch
> # User Derek Hower
The commit message could use some elaboration here :-).
Also, I saw in a later patch that libruby_isReady() got deleted... was
it ever used in the interim? If not, can we just qfold that patch in
here and never add it to begin with?
Steve
On Tue, Jan 19, 2010 at 3:19 PM, Derek Hower wrote:
> #
If that's true, is this patch even relevant or can we just get rid of it?
Steve
On Wed, Jan 20, 2010 at 12:43 PM, Derek Hower wrote:
> It doesn't. I believe that StateMachine.cc is blown away in a later merge.
>
> On Wed, Jan 20, 2010 at 2:08 PM, Beckmann, Brad wrote:
>> I'm a little confused h
. Same applies to caches if it
> have ECC (probably L2 or L3, L1 highly unlikely), but explicit partial
> load/stores are not very common and cached byte/half word stores goes to L1
> caches which usually have just parity which can be updated in the flight.
>
> - Original Message - Fr
e though as Matt found out.
>>>
>>> I believe the only addition that we previously made was to add a "unaligned"
>>> flag or something of that effect to the request structure so that we wouldnt
>>> fault when the swl/swr pairs were used in MIPS.
&g
tions that would require RMW
though (particularly since MIPS uses LL/SC for atomic ops, which is
the main reason you'd want RMW).
Have we discussed doing 3-byte memory ops on the list before? It's
clear it would require some new functionality at the read()/write()
ExecContext interface, but
My guess is that the instruction definition should be rewritten to do
a store of the correct number of bytes and not a read-modify-write. I
don't think there's a reason the store function shouldn't handle a
3-byte store; somebody correct me if I'm wrong.
Steve
On Tue, Jan 19, 2010 at 2:38 PM, Ma
Thanks for getting these patches out, Brad.
On Thu, Jan 14, 2010 at 10:19 PM, Brad Beckmann wrote:
> - These patches do not remove the old ruby config and rubymem files.
> However, once these patches are checked in, those old files won't be needed.
> Anyone have an opinion on how long they w
Yes and no... it basically works, but it's undergoing a lot of work
for better integration. If at all possible, I'd say hold off a month
or so and it'll be in much better shape.
Steve
On Mon, Dec 21, 2009 at 4:59 PM, wrote:
>
> Does m5 integrate ruby now? Can I simulate on chip network of ruby
On Tue, Jan 5, 2010 at 6:33 AM, nathan binkert wrote:
>> I started to do this, but the original includes were not sorted, so it
>> causes cascading problems through the whole patch set when you sort
>> everything the first time you add an include. I can see where that
>> could complicate integrat
On Mon, Jan 4, 2010 at 12:25 PM, nathan binkert wrote:
>> To answer your question about the ruby tester. While both the ruby tester
>> and memtester use false sharing to test coherence, they behave in different
>> ways. To my understanding, the Memtester has all cpus write a cache block
>> be
I spent the day working over the patches, so even though it might be
another few days until we send out updated versions, I wanted to
mention how I've addressed these issues:
On Mon, Dec 21, 2009 at 10:19 AM, Steve Reinhardt wrote:
> On Mon, Dec 21, 2009 at 9:03 AM, nathan binker
On Mon, Jan 4, 2010 at 2:37 PM, nathan binkert wrote:
>> So you were thinking it should be 'int buffer_size(10)'?
> No. This is what I was getting at about organic growth. I think = is
> the natural choice given what is there, but if we were to try to start
> with a fresh language that tried to
On Mon, Jan 4, 2010 at 2:26 PM, nathan binkert wrote:
>> I don't follow... are you complaining about the syntax we're
>> introducing, or the way we're parsing it? In this particular case,
>> the syntax seems straightforward to me, as we're just extending the
>> state-machine parameter block to al
On Mon, Dec 21, 2009 at 12:35 PM, nathan binkert wrote:
>> diff -r 8f73bf7c3c5e -r 5d3a90f0ef4c src/mem/slicc/parser.py
>> --- a/src/mem/slicc/parser.py Sat Dec 12 14:37:14 2009 -0800
>> +++ b/src/mem/slicc/parser.py Sat Dec 12 14:37:14 2009 -0800
>> @@ -418,6 +416,10 @@
>> "param : ty
On Mon, Dec 21, 2009 at 9:03 AM, nathan binkert wrote:
> Overall, things look pretty good. There are more or less four things
> that you've done that need work.
>
> 1) You created SimObjects for all of the ruby objects and in the
> process, you didn't give any help strings to any of the parameter
On Thu, Dec 17, 2009 at 1:59 PM, Gabriel Michael Black
wrote:
>
> Yeah, picking the microops was a big concern for me when I was
> starting out. If you remember, I closely based what we have now on
> that patent I found for what looks like an older, 32 bit version of
> AMD's integer microop set. T
On Wed, Dec 16, 2009 at 4:33 PM, Gabriel Michael Black
wrote:
> Quoting Vince Weaver :
>
>> On Wed, 16 Dec 2009, Steve Reinhardt wrote:
>>
>>> On Sun, Dec 13, 2009 at 8:57 PM, Vince Weaver wrote:
>>> > I did finish running and verifying spec2k on x86_64 (i
On Sun, Dec 13, 2009 at 8:57 PM, Vince Weaver wrote:
> I did finish running and verifying spec2k on x86_64 (it took longer than
> it should have due to an unfortunate power-outage on our cluster). The
> benchmarks all finished, and the retired instruction count matches actual
> hardware perf coun
On Sat, Dec 12, 2009 at 7:49 PM, nathan binkert wrote:
>> Some of these are really mine rather than Brad's, so don't be in too
>> much of a hurry to blame him if you see something you don't like.
>> We'll fix up the attributions before we push. I've got to get used to
>> using "qnew -U" now that
Some of these are really mine rather than Brad's, so don't be in too
much of a hurry to blame him if you see something you don't like.
We'll fix up the attributions before we push. I've got to get used to
using "qnew -U" now that we're using a shared patch queue.
Glad to see you got these out, Br
On Fri, Dec 4, 2009 at 3:39 PM, Korey Sewell wrote:
> Also, what's the changset revision # that you are referencing that broke
> things?
That hex code he sent is the changeset revision number, you can use it
directly as an argument to "-r". The little decimal numbers aren't
portable across diffe
I do have comments, just haven't had time to think them through and
type them out yet. It's on my to-do list for this afternoon.
Steve
On Fri, Dec 4, 2009 at 10:29 AM, Gabe Black wrote:
> Does anybody have any comments? I'd like to address any issues sooner
> rather than later.
>
> Gabe
>
> Gab
Your logic looks fine to me... I think Kevin would have to speak up to
say if there's any intended behavior here or if this is truly a bug.
Steve
On Tue, Dec 1, 2009 at 7:33 AM, Timothy M Jones wrote:
> Hi everyone,
>
> I've noticed a slight problem in using the branch predictor that's causing
>
On Wed, Dec 2, 2009 at 2:01 AM, Timothy M Jones wrote:
> Well, the problem is when you get speculative memory accesses. Even in
> the ISAs that don't need split loads and stores, an address on a
> speculative path can generated that requires splitting. Of course, these
> instructions are later s
Hi Tim,
It looks like you lost the initialization of isUncacheable... is that safe?
> diff --git a/src/cpu/base_dyn_inst.hh b/src/cpu/base_dyn_inst.hh
> --- a/src/cpu/base_dyn_inst.hh
> +++ b/src/cpu/base_dyn_inst.hh
> @@ -861,29 +871,14 @@
> Request *req = new Request(asid, addr, sizeof(T),
Looking at just the part I've left below, it looks like you're
separating out the split vs non-split calls at the top, and then they
combine back into common functions at the bottom... I think it would
be cleaner if we got rid of the separate calls, and just used NULL
values for the split packets a
This looks pretty straightforward to me...
On Mon, Nov 9, 2009 at 5:30 AM, Timothy M. Jones wrote:
> # HG changeset patch
> # User Timothy M. Jones
> # Date 1257772283 0
> # Node ID 861198113ecaf172b6d1e874cda4d13c92bdb38a
> # Parent e9f450b4b4f276dd3ed69dd63a540dda2796de60
> Power ISA: Add an
Hi Tim,
Sorry for the delay in getting back to you... it's been a busy few
weeks. I had to go back and look at your earlier patches to make
sense of this one. I'll send some comments on those separately.
I'd say the main thing that could be cleaned up here is that you want
to extend the "ExecCo
M5 has multiple CPU models, and the memory system can run in either a
timing or functional ("atomic") mode. The memory system only supports
one mode at a time, but you can mix simple and complex CPU models
simultaneously in a single system.
Steve
On Tue, Nov 17, 2009 at 9:37 AM, wrote:
>
> Doe
On Wed, Nov 18, 2009 at 8:39 PM, nathan binkert wrote:
>> ruby: cache configuration fix to use bytes
>> Changed cache size to be in bytes instead of kb so that testers can
>> use very
>> small caches and increase the chance of writeback races.
>
>
>> num_cores = 2
>> -l1_cac
EIO uses a flex-generated lexer to parse the trace file, and it
wouldn't surprise me at all if that's not thread-safe. Perhaps newer
versions of flex enable thread-safe lexing.
Steve
On Thu, Nov 12, 2009 at 4:09 AM, Stijn Souffriau
wrote:
> Hi again,
>
> I'm currently testing my code with eio t
On Wed, Nov 11, 2009 at 11:01 PM, nathan binkert wrote:
>> Yea, that's exactly the solution I was thinking of when I read the
>> first paragraph. It is a lot of code to change, but you could do it
>> all with one big regex replacement, so I don't think it's that big of
>> a hurdle.
> My gut prefe
On Wed, Nov 11, 2009 at 10:24 PM, nathan binkert wrote:
> Oh, there's one more thing. Currently, an event technically doesn't
> have access to the event queue that it was scheduled on. (It is in
> there if you #define DEBUG though). This makes the idea of a periodic
> event a little clumsy sinc
OK, I had completely forgotten about your binning thing... just went
back and looked at the code to refresh my memory. I thought you were
trying to add something like binning in with this extension you're
proposing, but it's already there. So what you're saying is that
there'd be a second overloa
On Wed, Nov 11, 2009 at 9:22 PM, nathan binkert wrote:
>> On the face of it, it doesn't sound that bad, but how often does this
>> really occur? If you have a SimObject that regularly has multiple
>> events scheduled at the same tick & priority, and is smart enough to
>> keep track of when that h
On the face of it, it doesn't sound that bad, but how often does this
really occur? If you have a SimObject that regularly has multiple
events scheduled at the same tick & priority, and is smart enough to
keep track of when that happens, why not have that SimObject chain its
own events itself (i.e
changeset c77e698abe9c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c77e698abe9c
description:
scons: deal with generated .py files properly
diffstat:
1 file changed, 7 insertions(+), 7 deletions(-)
src/SConscript | 14 +++---
diffs (44 lines):
diff -r a532
changeset 4b6fb0a99039 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4b6fb0a99039
description:
slicc: whack some of Nate's leftover debug code
diffstat:
1 file changed, 3 deletions(-)
src/mem/protocol/SConscript |3 ---
diffs (13 lines):
diff -r b95abe00dd9d -r 4
changeset 028047200ff7 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=028047200ff7
description:
slicc: tweak file enumeration for scons
Right now .cc and .hh files are handled separately, but then
they're just munged together at the end by scons, so it
changeset 9c3577d9704a in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9c3577d9704a
description:
stats: update memtest-ruby
I don't know if the new stats are right or not, but we've
been too long with a useless regression so I'm just going
to updat
changeset c79d72abdbe5 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c79d72abdbe5
description:
o3: get rid of unused physmem pointer
diffstat:
3 files changed, 7 deletions(-)
src/cpu/o3/cpu.cc|1 -
src/cpu/o3/cpu.hh|3 ---
src/cpu/o3/thre
On Wed, Oct 28, 2009 at 10:08 AM, nathan binkert wrote:
> > You'll need to add reference outputs under tests/{quick,long} as well.
> Yeah, we already have a 00.hello test in there. I was most concerned
> about making sure that it got compiled.
>
> OK, I did look for it but somehow missed it the
You'll need to add reference outputs under tests/{quick,long} as well.
Steve
On Wed, Oct 28, 2009 at 9:53 AM, Ali Saidi wrote:
>
> The regressions on zizzer execute util/regress in the cloned repository so
> I believe so.
>
> Ali
>
> On Wed, 28 Oct 2009 09:55:26 -0700, nathan binkert
> wrote:
ugh I can understand if that wasn't perfectly obvious from
reading the code :-).
Steve
>
> Tim
>
> On Wed, 21 Oct 2009 16:35:32 +0100, Steve Reinhardt
> wrote:
>
> > Actually no... x86 handles this by hacking up the CPU model to
> > dynamically
> > generate t
best place to do this? In LSQUnit::insertStore would be
> the
> >
> > easiest place, but is that the correct place for it? However, since this
>
> > is Power specific, maybe it should be handled within the code for this
> ISA
> >
> > only? Any thoughts on thi
Brad's issues with the timer device and checkpointing reminded me that I
wasn't really happy with that code; in particular, the redundant storage in
both clock_data[] and curTime seemed bound to cause problems when they got
out of sync, and in fact Brad's checkpointing fix was incomplete in that it
gt;
> Ali
>
>
> On Mon, 19 Oct 2009 13:05:21 -0700, Steve Reinhardt
> wrote:
> > On Mon, Oct 19, 2009 at 12:46 PM, nathan binkert
> wrote:
> >
> >>
> >> > StaticInst::decode() Perhaps replication would be a good place to
> >> > start.
On Mon, Oct 19, 2009 at 12:46 PM, nathan binkert wrote:
>
> > StaticInst::decode() Perhaps replication would be a good place to start.
> I
> > think the structure is just accessed too much to have any kind of
> locking.
> I agree that replication can work, but I'd say we start with a rwlock
> and
The NO_FAULT behavior in Alpha is still the correct behavior model in my
opinion (and corresponds to what Ali described). I had not realized that
the implementation was Alpha-specific though; thanks for tracking that down,
Gabe.
I'm also amazed that the PREFETCH flag is not used anywhere... that'
Hi Tim,
That assertion is just letting you know that it doesn't make sense to
translate a request that crosses a page boundary. I'm guessing that in our
other RISC ISAs we check alignment first, so you get an alignment fault
before you even try to translate the access. The alignment fault will t
Setting NO_FAULT in the mem flags should be all you need to do for a
prefetch. This is how software prefetch instructions work on Alpha (or at
least worked at some point in the past). If something in a CPU model is not
handling NO_FAULT properly, then I'd say that's your bug.
Steve
On Fri, Oct
I'm sure Tim knows best wherher he's implemented POWER or PowerPC...
If it is the latter, I'd favor using PPC for naming just to keep
things brief.
Steve
On 10/16/09, nathan binkert wrote:
> currently the new PowerPC port is in the src/arch/powerpc directory
> and the isa is called PowerpcISA.
Note that running 'util/regress --variants=debug,opt,fast' should
capture all these (except POWERPC_SE) in a much shorter command line.
Once POWERPC_SE is ready to go it should be added to that script too.
Steve
On Thu, Oct 15, 2009 at 4:01 PM, nathan binkert wrote:
> I'm trying to compile absol
On Wed, Oct 14, 2009 at 5:10 PM, nathan binkert wrote:
>> + reschedule(tickEvent, curTick + tickEvent.when());
>
> This seems pretty suspect to me. Generally, when we unserialize
> events, we first serialize the event time and then schedule it later.
> In fact, the way that the existing event
On Wed, Oct 14, 2009 at 5:10 PM, nathan binkert wrote:
>> + reschedule(tickEvent, curTick + tickEvent.when());
>
> This seems pretty suspect to me. Generally, when we unserialize
> events, we first serialize the event time and then schedule it later.
> In fact, the way that the existing event
, Timothy M Jones wrote:
> Steve,
>
> Would it be possible for you to tell me what you meant by this:
>
> On Fri, 28 Aug 2009 15:23:15 +0100, Steve Reinhardt
> wrote:
>>
>> - For the times patch, you should find the global
>> microseconds-per-tick value; see
changeset 300266bf68ec in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=300266bf68ec
description:
bus: add assertion to catch illegal retry
on mem-inhibited transaction.
diffstat:
1 file changed, 3 insertions(+)
src/mem/bus.cc |3 +++
diffs (13 lines):
diff
Hi Korey,
I'm not quite sure what your concern is here... if it's just that the
L1 cache latency is multiple cycles, that's not at all unusual on
high-performance processors.
Steve
On Fri, Oct 2, 2009 at 6:52 PM, Korey Sewell wrote:
> Hey all,
> there may be a subtle flaw in how we configure CP
Hi Brad,
As part of the switch to the 'h...@m5sim' mercurial access scheme, which
doesn't require logins to commit to the repositories, all of the
pre-existing accounts that were there only to enable people to commit
were disabled, including yours. If there's a reason you need a shell
on m5sim.or
Hi Korey,
I didn't see where you were using this feature, so I don't know if it
would work, but it would be much cleaner just to add another enum
value to the Event::Priority enum than to treat it like an integer and
add an offset to it. With what you're doing here, you've got no
control over how
Hi Korey,
Are you aware of Param.Enum()? It's a much cleaner way to implement
the string-based switch thing you have below. I'm not sure it's
documented anywhere, but see MemoryMode in sim/System.py and OpClass
in cpu/FuncUnit.py for examples.
Steve
On Thu, Oct 1, 2009 at 1:08 PM, Korey Sewell
changeset e0f3287fc680 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e0f3287fc680
description:
rundiff: Don't flush stdout until after postcontext is printed.
diffstat:
1 file changed, 8 insertions(+), 2 deletions(-)
util/rundiff | 10 --
diffs (30 lines):
changeset 8b5bc1a777bc in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8b5bc1a777bc
description:
O3: Add flag to control whether faulting instructions are traced.
When enabled, faulting instructions appear in the trace twice
(once when they fault and again
changeset 3199397fd905 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=3199397fd905
description:
Minor cleanup: Use the blockAlign() method where it applies in the
cache.
diffstat:
2 files changed, 4 insertions(+), 4 deletions(-)
src/mem/cache/base.hh |2 +-
s
changeset 4df6f4bd36cd in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4df6f4bd36cd
description:
O3: Mark fetch stage as active if it faults.
Otherwise if the rest of the pipeline is idle then
fault will never propagate to commit to be handled,
cau
changeset 874f2ee2f115 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=874f2ee2f115
description:
Force prefetches to check cache and MSHRs immediately prior to issue.
This prevents redundant prefetches from being issued, solving the
occasional 'needsExclus
On Wed, Sep 23, 2009 at 2:53 PM, Vince Weaver wrote:
> On Wed, 23 Sep 2009, Steve Reinhardt wrote:
>
>> For TTY-related ioctls, returning ENOTTY is the right behavior, so
>> there's no need to print a warning. To me it's a step backward to
>> start printing
On Wed, Sep 23, 2009 at 2:49 PM, Vince Weaver wrote:
>
> In most cases the Linux syscalls are fairly similar across ISA's. The
> biggest outlier is Alpha, which unfortunately seems to be the original
> version that the rest of m5 cut-and-pasted from.
Worse yet, the original implementation was fo
I meant to add that changing the default behavior for unrecognized
ioctls from a fatal error to a warning is fine by me though.
Steve
On Wed, Sep 23, 2009 at 9:13 AM, Steve Reinhardt wrote:
> For TTY-related ioctls, returning ENOTTY is the right behavior, so
> there's no need to prin
There's a copyOut() method on TypedBufferArg (inherited from
BaseBufferArg) specifically for this purpose, so just add
tp.copyOut(rc->getMemPort()) right after the assignment . It's just a
wrapper around writeBlob (for now), but it's nice in that it handles
the size etc. for you.
Steve
On Wed, S
For TTY-related ioctls, returning ENOTTY is the right behavior, so
there's no need to print a warning. To me it's a step backward to
start printing a warning for something that we're actually handling
correctly. If we're not properly identifying which ioctls are
TTY-related, I'd rather try and fi
On Tue, Sep 22, 2009 at 11:38 PM, Gabe Black wrote:
>
> I think there's been at least a superficial effort to
> factor out the common parts and template on, say, an ISA's definition of
> a particular data structure as necessary, but pulling the whole thing
> into a common spot for all ISAs is like
think
> that would make a difference but maybe it did. Will check it out!
>
> On Sun, Sep 20, 2009 at 6:17 PM, Steve Reinhardt wrote:
>>
>> I did a manual run just to kick things off, and it looks like there
>> are some small stats changes in MIPS_SE as well as the ruby pr
/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing-ruby
passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby
FAILED!
See /z/m5/regression/regress-2009-09-20-17:54:55 for details.
On Sun, Sep 20, 2009 at 2:54 PM, Steve Reinhardt wrote:
> FYI, I'm switc
FYI, I'm switching the regressions over to run directly on zizzer
until this is fixed.
Steve
On Sun, Sep 20, 2009 at 12:47 AM, Cron Daemon
wrote:
> scons: *** [build/ALPHA_SE/params/params_wrap.fo] Error 1
> scons: *** [build/ALPHA_SE/python/swig/debug_wrap.fo] Error 1
> scons: *** [build/ALPHA_
On Fri, Sep 18, 2009 at 12:38 PM, nathan binkert wrote:
> I generally start with much smaller
> patches now that I'm used to it, but I often have many patches
> qpushed, fix many bugs create a patch on top called "progress" and
> then pull the bits out of progress and put them into the patches wh
On Fri, Sep 18, 2009 at 11:52 AM, nathan binkert wrote:
>>> - In hindsight, one may see the items in this patch as unrelated,
>>> but I initially created this patch with the sole goal of adding
>>> large memory support to Ruby. It turned out I encountered a lot of
>>> issues throughout the code,
On Fri, Sep 18, 2009 at 12:25 PM, Beckmann, Brad wrote:
> Darn...I was hoping -X would work. So by manually creating multiple patches,
> you mean qnew a few almost empty patches and then cut-and-paste the one patch
> into those new patch files, right?
Or alternatively you can just create the n
aming
>
> On Wed, Sep 16, 2009 at 8:19 AM, nathan binkert wrote:
>> Sounds good. I'll update it.
>>
>> Nate
>>
>> On Wed, Sep 16, 2009 at 8:01 AM, Steve Reinhardt wrote:
>>> I think if we're going to say that some fields have underscores an
On Wed, Sep 16, 2009 at 12:25 PM, nathan binkert wrote:
>> It says on the coding guidelines page "Lines must be a maximum of 78
>> characters long". Does that include the space characters used for
>> indentation too?
> Yes. 78 characters total. There are many reasons that this is a good
> policy
gt; publich ones should not.
>
> What do you think? A style change of course does not require that all
> code change overnight.
>
> Nate
>
> On Sun, Aug 2, 2009 at 4:31 PM, Steve Reinhardt wrote:
>> Fine with me... one thing to clarify though is whether in the long run:
>&
On Tue, Sep 15, 2009 at 5:14 AM, Gabe Black wrote:
>>
>> I'll take a look at trying to do something semi-automatic to split
>> things up. In addition to putting the decide function in a separate
>> file, maybe we could add a directive like
>>
>> set decoder_output "";
>>
>> that would cause all
701 - 800 of 1287 matches
Mail list logo
