Re: [m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression --scratch all

2008-03-16 Thread Steve Reinhardt
I believe all the FAILEDs below are just the long runs whose stats didn't get updated after my cache changes. I can't tell what happened on the last one (the Error 3), so I'm hypothesizing that it was just a pool glitch and I'm rerunning now. Steve On Sun, Mar 16, 2008 at 8:10 AM, Cron Daemon

Re: [m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression --scratch all

2008-03-16 Thread Steve Reinhardt
aborted at cycle 10209991750 Aborted (core dumped) Ali On Mar 15, 2008, at 9:19 PM, Ali Saidi wrote: Fixed... Attached is a memtest diff that makes the problem show up in 1 hour rather than 6. Ali memtest1.diff On Mar 15, 2008, at 7:23 PM, Steve Reinhardt wrote: Does

Re: [m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression --scratch all

2008-03-16 Thread Steve Reinhardt
looks like it... On Sun, Mar 16, 2008 at 11:37 AM, nathan binkert [EMAIL PROTECTED] wrote: Generally, yes. Memory leak? 2008/3/16 Steve Reinhardt [EMAIL PROTECTED]: Funny, I got this error: system.cpu7: completed 630 read accesses @9833512177 system.cpu5: completed 630 read

Re: [m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression --scratch all

2008-04-07 Thread Steve Reinhardt
On Mon, Apr 7, 2008 at 9:08 AM, Ali Saidi [EMAIL PROTECTED] wrote: Well, yes, but we'll have to duplicate this code in the libelf SConscript: # Do this after we save setting back, or else we'll tack on an # extra 'qdo' every time we run scons. if env['BATCH']: env['CC'] =

Re: [m5-dev] big memory on a 32 bit machine

2008-04-26 Thread Steve Reinhardt
Is it too difficult to track down which piece of BIOS info you copied contains the DRAM size, or copy the info from a machine with less RAM? In the long run we'll want to make it configurable, and clearly in the real world it's OK to have a PC with 4GB of RAM... On Sat, Apr 26, 2008 at 3:46 PM,

Re: [m5-dev] tracing data for stores in simple CPU

2008-05-03 Thread Steve Reinhardt
Yea, sounds like a bug to me. Steve On Sat, May 3, 2008 at 8:55 AM, nathan binkert [EMAIL PROTECTED] wrote: I'm guessing the answer is no. Nate On Sat, May 3, 2008 at 8:34 AM, Gabe Black [EMAIL PROTECTED] wrote: That turns on the output in the trace printing code, but it can't print

Re: [m5-dev] Author Map

2008-05-20 Thread Steve Reinhardt
Do umich.edu addresses really last forever? I know I only got 'stever' after they found that the previous owner had left. Maybe that policy applies to students but not faculty... though I pity the fool who gets stuck with my email address if they take it away from me. On Mon, May 19, 2008 at

Re: [m5-dev] Author Map

2008-05-20 Thread Steve Reinhardt
small number of non-alumni, it's not worth trying to keep the two groups separate. Anyway, which address do you want? gmail? Nate 2008/5/20 Steve Reinhardt [EMAIL PROTECTED]: Do umich.edu addresses really last forever? I know I only got 'stever' after they found that the previous owner

Re: [m5-dev] Author Map

2008-05-20 Thread Steve Reinhardt
, especially where there were just usernames with no e-mail address from the BK days. People can pick whatever they want. Nate 2008/5/20 Steve Reinhardt [EMAIL PROTECTED]: I just emailed ITD to see what their policy is. Lots of choices... I'm guessing the only way that DCO would stop

Re: [m5-dev] local APIC timer and bus frequency

2008-05-22 Thread Steve Reinhardt
On Wed, May 21, 2008 at 5:44 PM, Gabe Black [EMAIL PROTECTED] wrote: The kernel is now getting to a point where it's trying to calibrate the timer in the local APIC against the TSC register. In order to mimic that, I'm going to need to create an event to fire when the timer is supposed to

Re: [m5-dev] local APIC timer and bus frequency

2008-05-24 Thread Steve Reinhardt
Thanks for the email... can't say I really follow all the nuances after a quick read, but I'm glad you're thinking about it. Just a few comments off the top of my head: The common indexing scheme across all register types is something we inherited from SimpleScalar. It's not ideal for actually

Re: [m5-dev] Test Repository

2008-06-07 Thread Steve Reinhardt
My biggest worry about 3-6 months is that we often have fixes that are important and more recent than 3-6 months. Beta 5 is barely three months old and has at least two important patches, right? I was just going to use that same evidence to argue the opposite... the fact that beta5 is 3

Re: [m5-dev] Test Repository

2008-06-07 Thread Steve Reinhardt
Sort of a multi-reply here... On Sat, Jun 7, 2008 at 11:36 AM, Ali Saidi [EMAIL PROTECTED] wrote: To jump in here, the thing is we're not finding these bugs. Saying there needs to be 3 months of testing before we release something marked stable only works if its likely that the people running

[m5-dev] cpu2000.py output files

2008-06-10 Thread Steve Reinhardt
How is cpu2000.py supposed to work? I'm in the head of the repo, and if I try to run swim on zizzer I get this: % build/ALPHA_SE/m5.debug configs/example/se.py --bench=swim [...] command line: build/ALPHA_SE/m5.debug configs/example/se.py --bench=swim Global frequency set at 1 ticks

Re: [m5-dev] namespaces for python SimObjects

2008-06-12 Thread Steve Reinhardt
On Thu, Jun 12, 2008 at 11:26 AM, Gabe Black [EMAIL PROTECTED] wrote: How about instead of Params.some_class the syntax would be Params(some_class) where Params is more like a class than a module? Then you could look up the information for the class you're dealing with without ever having to

Re: [m5-dev] namespaces for python SimObjects

2008-06-12 Thread Steve Reinhardt
On Thu, Jun 12, 2008 at 5:44 PM, nathan binkert [EMAIL PROTECTED] wrote: How about instead of Params.some_class the syntax would be Params(some_class) where Params is more like a class than a module? Then you could look up the information for the class you're dealing with without ever having

Re: [m5-dev] namespaces for python SimObjects

2008-06-12 Thread Steve Reinhardt
On Thu, Jun 12, 2008 at 5:51 PM, nathan binkert [EMAIL PROTECTED] wrote: I was wondering why we had both 'type' and 'cxx_classname'... last time I recall working on that code (before Nate finished the params auto-gen stuff), the point of 'type' was to be the C++ class name. When is the

[m5-dev] m5: 3 new changesets

2008-06-12 Thread Steve Reinhardt
changeset 9ffc2be2d925 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=9ffc2be2d925 summary: Get rid of bogus cache assertion. changeset b84a60dbf862 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=b84a60dbf862 summary: Get rid of bogus bus assertion.

Re: [m5-dev] M5

2008-06-13 Thread Steve Reinhardt
On Fri, Jun 13, 2008 at 3:33 PM, nathan binkert [EMAIL PROTECTED] wrote: Today, it is our pleasure to announce the public availability of the M5 repository. Great job everybody. Hopefully Friday the 13th doesn't turn out to be a problem :) Thanks to everyone for all the effort. BTW, the

Re: [m5-dev] m5-stable: 11 new changesets

2008-06-15 Thread Steve Reinhardt
I sympathize with Ali's concerns... the current situation is pretty much the opposite extreme of the 3-6 month release cycle I was advocating not that long ago. My main motivation was that a longer cycle would allow more time for people to find problems, and the criticism was that a lot of the

Re: [m5-dev] m5: port: Clean up default port setup and port switchover code.

2008-06-15 Thread Steve Reinhardt
On Sun, Jun 15, 2008 at 9:37 PM, Nathan Binkert [EMAIL PROTECTED] wrote: changeset 758c2413765a in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=758c2413765a summary: port: Clean up default port setup and port switchover code. [...] diff -r 7c18f61da616 -r 758c2413765a

Re: [m5-dev] m5: port: Clean up default port setup and port switchover code.

2008-06-16 Thread Steve Reinhardt
On Mon, Jun 16, 2008 at 8:49 AM, nathan binkert [EMAIL PROTECTED] wrote: I don't think this works, given that you've (still) got a single global static instance of DefaultPeerPort... right? I ask because this patch looks frighteningly familiar... I just did the same thing last week (including

Re: [m5-dev] m5: port: Clean up default port setup and port switchover code.

2008-06-16 Thread Steve Reinhardt
On Mon, Jun 16, 2008 at 9:58 AM, nathan binkert [EMAIL PROTECTED] wrote: I was specifically talking about the error message that I quoted in my earlier response. Since there's only one global static instance, the 'peer' field will point to the last initialized port, so the error message will

Re: [m5-dev] m5: port: Clean up default port setup and port switchover code.

2008-06-16 Thread Steve Reinhardt
I was strictly talking about the port.cc changes... my diff doesn't touch base.cc, and I don't think it does much in port.hh either. So in that context, your answer seems to be no... Steve On Mon, Jun 16, 2008 at 11:33 AM, nathan binkert [EMAIL PROTECTED] wrote: Is there anything in your

[m5-dev] Port confusion

2008-06-20 Thread Steve Reinhardt
I'm trying to clean up the DefaultPort code so that when you leave a port unconnected and then try to use it you get a message that tells you which port was unconnected. This basically involves dynamically allocating a DefaultPort every time you create a normal port to serve as its peer until it

[m5-dev] m5: 2 new changesets

2008-06-20 Thread Steve Reinhardt
changeset 94a7bb476fca in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=94a7bb476fca summary: Generate more useful error messages for unconnected ports. changeset 88f1e9295945 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=88f1e9295945 summary: Make bus

Re: [m5-dev] string

2008-06-21 Thread Steve Reinhardt
It shouldn't affect stable yet, since the sim_object_params.hh file just got pushed by Nate a couple days ago (since stable was last updated). Go ahead and push it to m5. Steve 2008/6/21 Gabe Black [EMAIL PROTECTED]: I don't know if this affects stable or not, but at least X86_FS does not

Re: [m5-dev] m5-stable: Checkpoinging/SWIG: Undo part of changeset 5464 since...

2008-06-24 Thread Steve Reinhardt
See Brad's email to m5-users. On Tue, Jun 24, 2008 at 5:40 PM, nathan binkert [EMAIL PROTECTED] wrote: What exactly broke? I was using checkpointing successfully with that change. Also, In the future, please use the full changeset id since the numbers change all the time. Nate On Tue,

Re: [m5-dev] m5: 2 new changesets

2008-06-27 Thread Steve Reinhardt
I think the easiest short-term fix is just to revert that changeset... the only thing it provides is better error messages, so there's no big loss for that. We can resurrect it once we fix the memory leak. Steve On Fri, Jun 27, 2008 at 5:32 PM, nathan binkert [EMAIL PROTECTED] wrote: I thought

Re: [m5-dev] [PATCH] After a checkpoint (and thus a stats reset), the not_idle_fraction/notIdleFraction statistic is really wrong

2008-06-29 Thread Steve Reinhardt
On Sun, Jun 29, 2008 at 4:45 PM, Ali Saidi [EMAIL PROTECTED] wrote: Anyone care to comment on the odd naming of the Status instance? It shouldn't just be status because that is confusing with Port::Status, but _status seems a bit strage too. Isn't it just to avoid conflict with the status()

Re: [m5-dev] [PATCH 2 of 2] Change everything to use the cached virtPort rather than created their own each time

2008-06-29 Thread Steve Reinhardt
On Sun, Jun 29, 2008 at 4:49 PM, Ali Saidi [EMAIL PROTECTED] wrote: one question is how to enforce encourage objects that call getVirtPort() to not cache the virtual port since if the CPU changes out from under them it will be worse than useless. Perhaps a null function like

Re: [m5-dev] [PATCH 2 of 2] Change everything to use the cached virtPort rather than created their own each time

2008-06-30 Thread Steve Reinhardt
On Mon, Jun 30, 2008 at 8:26 AM, Ali Saidi [EMAIL PROTECTED] wrote: On the other hand, if during the switchover the new CPU starts connecting to the same ports that the old one did, won't my once and future patch mean that the old CPU's port gets dicsonnected and hooked up to a defaultPort,

[m5-dev] modular coherence protocol design document

2008-07-02 Thread Steve Reinhardt
Nate and I had some discussions the other week along with Brad Beckmann about improving M5's ability to support other coherence protocols. I put together an initial design document on the wiki here: http://m5sim.org/wiki/index.php/Modular_Coherence_Protocols Note that even though I tried to

Re: [m5-dev] modular coherence protocol design document

2008-07-02 Thread Steve Reinhardt
getting ready to go to California but then I'll spend a really long time in a car where I could read this over at length. Gabe Steve Reinhardt wrote: Nate and I had some discussions the other week along with Brad Beckmann about improving M5's ability to support other coherence protocols. I

Re: [m5-dev] RefCountingPtr problem on alpha fs

2008-07-05 Thread Steve Reinhardt
Is this a bug in the current repo head? If so, please be more specific so we can commit the patch... Thanks, Steve On Fri, Jul 4, 2008 at 3:23 PM, Rick Strong [EMAIL PROTECTED] wrote: Your second paragraph seems to be spot on. The problem was a redundant delete of pkt-req in

Re: [m5-dev] m5: 2 new changesets

2008-07-08 Thread Steve Reinhardt
I think someone just needs to reapply it and test it. Steve On Mon, Jul 7, 2008 at 9:11 PM, nathan binkert [EMAIL PROTECTED] wrote: So, you committed that fix to the dynamic creating of virtual ports. What's the status of this diff? Well, I think the first step is understanding why the

Re: [m5-dev] m5: 2 new changesets

2008-07-08 Thread Steve Reinhardt
should find those other N:1 cases and fix them too.) Steve On Tue, Jul 8, 2008 at 6:52 AM, Steve Reinhardt [EMAIL PROTECTED] wrote: I think someone just needs to reapply it and test it. Steve On Mon, Jul 7, 2008 at 9:11 PM, nathan binkert [EMAIL PROTECTED] wrote: So, you committed that fix

Re: [m5-dev] [PATCH 0 of 3] New event queue diff

2008-07-09 Thread Steve Reinhardt
Thanks, I'm happier now. It's a little funny that in the first diff you split out the Debug structure and in the second diff you fold it back in again... as I was reading the first diff I thought didn't we decide not to do that?. Not a big deal, just seems redundant. Committing the FIFO code

Re: [m5-dev] notify e-mails

2008-07-11 Thread Steve Reinhardt
On a separate but related note, does anybody care if we change the notify template to include the full commit description and not just the first-line summary? As far as I can tell, the single-changeset template does this already, but since we're using the changegroup hook, it just uses the first

Re: [m5-dev] Two patch sets

2008-07-11 Thread Steve Reinhardt
Nate, Did you ever get Michael's libm5 diff into the tree? I don't see any evidence of it. We actually have a need for it so it would be great to have the code ASAP... if there are issues with committing it, could you just send it to us? Actually I don't see evidence of Michael's other patches

Re: [m5-dev] submit patches: Mesh2D, directory coherence, and multithreading

2008-07-12 Thread Steve Reinhardt
No, please base your patches on m5 (the development repo) rather than m5-stable, as that's where we'll want to integrate them. Thanks, Steve 2008/7/12 jiayuan meng [EMAIL PROTECTED]: I'm going to pull the repository of m5_stable and base my patches upon this version, will that be fine?

[m5-dev] new assertion flavor / object cprintf format

2008-07-14 Thread Steve Reinhardt
I'm working on adding a new flavor of assertion inspired by what I've seen in some unit-testing frameworks. The idea is that if you assert foo == 3 and it fails, it would be nice to know what the actual value of foo was without having to rerun the simulation or load up the core dump (if you even

Re: [m5-dev] new assertion flavor / object cprintf format

2008-07-14 Thread Steve Reinhardt
On Mon, Jul 14, 2008 at 2:30 PM, Gabriel Michael Black [EMAIL PROTECTED] wrote: Sorry to butt into the conversation, but I've thought before that it would be really handy to have asserts that printed out a message rather than just the condition that triggered them. It would be handy to be able

[m5-dev] caches, address ranges, etc.

2008-07-14 Thread Steve Reinhardt
I'm running into trouble with multilevel caches, default responders, and misspeculated accesses, and the way I'd like to fix it is to overhaul things a bit... so I'd like to solicit some input on whether it'll work before I go at it. The setup is a little complicated, but the basic issues are:

Re: [m5-dev] new assertion flavor / object cprintf format

2008-07-15 Thread Steve Reinhardt
On Tue, Jul 15, 2008 at 9:33 AM, Gabriel Michael Black [EMAIL PROTECTED] wrote: On Mon, 14 Jul 2008, nathan binkert wrote: I'd argue that I'd prefer to get rid of cassert and create our own assert for everything if we're going to start messing with this. This also argues that the name assert

Re: [m5-dev] caches, address ranges, etc.

2008-07-15 Thread Steve Reinhardt
I plan to leave the existing explicit default responders alone, yes. I will probably need to add an explicit default responder on the main memory bus to deal with misspeculated cacheable accesses to replace all the implicit default responders I'll be getting rid of. On busses where the caches are

[m5-dev] changeset in m5: Add missing newlines to Bus DPRINTFs.

2008-07-15 Thread Steve Reinhardt
changeset c1f203a35cc3 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=c1f203a35cc3 description: Add missing newlines to Bus DPRINTFs. diffstat: 1 file changed, 1 insertion(+), 1 deletion(-) src/mem/bus.cc |2 +- diffs (16 lines): diff -r 90d6811d5ea6 -r

[m5-dev] changeset in m5: Use ReadResp instead of LoadLockedResp for Load...

2008-07-15 Thread Steve Reinhardt
changeset 52bcc301b467 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=52bcc301b467 description: Use ReadResp instead of LoadLockedResp for LoadLockedReq responses. diffstat: 2 files changed, 3 insertions(+), 2 deletions(-) src/cpu/simple/timing.cc |2 +-

[m5-dev] changeset in m5: Get rid of useless m5_assert macro.

2008-07-15 Thread Steve Reinhardt
changeset 992aeed13743 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=992aeed13743 description: Get rid of useless m5_assert macro. Its only purpose was to print the cycle number but that already happens in the SIGABRT handler. No one used it anyway.

Re: [m5-dev] Fix some problems of Prefetch

2008-07-15 Thread Steve Reinhardt
Thanks! I'll get those patches into the repository. Steve 2008/7/15 Bao Yungang [EMAIL PROTECTED]: I found the prefetcher unit doesn't work. The CPI doesn't change with or without prefetcher (tagged). I have found the reason: 1. when Cache::MemSidePort::sendEvent is scheduled, the

Re: [m5-dev] Execution Tracing

2008-07-23 Thread Steve Reinhardt
Funny, I just noticed this the other day myself. The default behavior should definitely be to print at commit (as we do now) because we want to be able to generate a program-order list of committed instructions to see what the CPU is doing functionally, and to compare with simpler models to

Re: [m5-dev] Fix some problems of Prefetch

2008-07-23 Thread Steve Reinhardt
Hi Yungang, I'm trying to commit your patches, and I'm running intop a problem with this line: std::liststrideEntry*::iterator minPos = NULL; g++ 4.2.3 gives me: error: conversion from 'long int' to non-scalar type 'std::_List_iteratorStridePrefetcher::strideEntry*' requested Also,

Re: [m5-dev] Integrating DRAMSim into M5

2008-07-25 Thread Steve Reinhardt
Hi Yungang, Thanks for the patch. Have you corresponded with any of the DRAMSim developers about this? Prof. Bruce Jacob told me a while ago that they had already integrated DRAMSim into M5, but hadn't gotten around to sending us the code. I don't know if their integration has any more

[m5-dev] default physical memory latency

2008-07-31 Thread Steve Reinhardt
So we just got mildly bit by the '1t' default latency on PhysicalMemory, so I'm ready to change it to something a little more realistic (say 30ns). This will involve rerunning all the regressions to generate new stats. If anyone is thinking of committing anything that will require a full stats

Re: [m5-dev] Default file renames

2008-08-01 Thread Steve Reinhardt
On Fri, Aug 1, 2008 at 5:52 PM, nathan binkert [EMAIL PROTECTED] wrote: I sent out e-mail a while ago about changing some default output file names. Yea, the other discussion we've been having about output redirection reminded me of this, and made me wonder what had happened here... I guess

[m5-dev] changeset in m5: Make default PhysicalMemory latency slightly mo...

2008-08-03 Thread Steve Reinhardt
changeset cf280b3621cf in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=cf280b3621cf description: Make default PhysicalMemory latency slightly more realistic. Also update stats to reflect change. diffstat: 96 files changed, 356 insertions(+), 611 deletions(-)

Re: [m5-dev] [PATCH] SCons: add code to provide a libm5 shared library

2008-08-03 Thread Steve Reinhardt
That seems pretty cool to me. I remember when we decided to integrate python we had the extending vs embedding debate, and now it looks like we can have it both ways. Steve On Sun, Aug 3, 2008 at 8:50 PM, nathan binkert [EMAIL PROTECTED] wrote: So, the patch I committed earlier today allows

[m5-dev] changeset in m5: Add -r/-e options to redirect stdout/stderr.

2008-08-03 Thread Steve Reinhardt
changeset e5fbd38bc828 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=e5fbd38bc828 description: Add -r/-e options to redirect stdout/stderr. Better than using shell since it automatically uses -d directory for output files (creating it as needed).

[m5-dev] changeset in m5: Minor fix for test/SConscript... forgot to 'qre...

2008-08-03 Thread Steve Reinhardt
changeset 2764c7769ee3 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=2764c7769ee3 description: Minor fix for test/SConscript... forgot to 'qref' before 'qdel', argh. diffstat: 0 files changed diffs (12 lines): diff -r abb8846b2e62 -r 2764c7769ee3 tests/SConscript

[m5-dev] changeset in m5: Get rid of outputStream... wasn't really being ...

2008-08-04 Thread Steve Reinhardt
changeset cdcfaac59d70 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=cdcfaac59d70 description: Get rid of outputStream... wasn't really being used (except for warn()) and new -r/-e options make it not worth fixing. diffstat: 2 files changed, 6

[m5-dev] changeset in m5: Make time format in 'started' line same as 'com...

2008-08-04 Thread Steve Reinhardt
changeset 10a17e8a6d35 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=10a17e8a6d35 description: Make time format in 'started' line same as 'compiled'. Also make -B output consistent with normal header, and only include actual build options. diffstat: 1

Re: [m5-dev] changeset in m5: style

2008-08-12 Thread Steve Reinhardt
On the topic of style violations, I've seen an increasing number of 'if(' and 'for(' (with no space) creeping in (see below). Another thing I've seen that irritates me (but isn't officially banned by the style code ... yet ...) is C++-style comments with no space between the // and the comment:

Re: [m5-dev] broadcast memory system packets

2008-08-12 Thread Steve Reinhardt
Right now the bus supports broadcast, but only for snooping. Also for future interconnects there isn't necessarily a plan to maintain broadcast capability (though of course if it's really needed then we would have to). Is there any particular reason (other than efficiency) why having the

Re: [m5-dev] broadcast memory system packets

2008-08-13 Thread Steve Reinhardt
at the state of the others. Gabe Steve Reinhardt wrote: Right now the bus supports broadcast, but only for snooping. Also for future interconnects there isn't necessarily a plan to maintain broadcast capability (though of course if it's really needed then we would have

Re: [m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression quick

2008-08-18 Thread Steve Reinhardt
As far as I can tell, this is an NFS sync issue on the pool with the strip command... the link and the strip are run on separate pool nodes, and strip fails to find the unstripped binary and dies. Did someone get aggressive about farming things out? I thought we originally only did compiles and

Re: [m5-dev] zero registers

2008-08-24 Thread Steve Reinhardt
At least for Alpha ALU ops, all the ones with a dest reg of r31 should get decoded to nop. The original code for zeroing out the zero register was inherited from SimpleScalar (believe it or not), which did not handle r31 destinations specially and thus needed to reset the reg to zero before every

Re: [m5-dev] zero registers

2008-08-25 Thread Steve Reinhardt
, and that you can have an arbitrary number of special registers that behave in arbitrary ways. Gabe Steve Reinhardt wrote: At least for Alpha ALU ops, all the ones with a dest reg of r31 should get decoded to nop. The original code for zeroing out the zero register was inherited from

Re: [m5-dev] zero registers

2008-08-25 Thread Steve Reinhardt
could write to the zero register to special case them all. In a lot of cases in x86 at least you can't blindly replace the instruction with a nop because, for instance, the control flags need to be updated. Gabe Quoting Steve Reinhardt [EMAIL PROTECTED]: What about dependencies? One thing

Re: [m5-dev] bug in x86

2008-09-02 Thread Steve Reinhardt
It's fine with me, since it probably doesn't touch anything that's widely used... if no one else objects, I'd say go for it. Steve On Tue, Sep 2, 2008 at 2:19 PM, [EMAIL PROTECTED] wrote: Quoting Gabe Black [EMAIL PROTECTED]: Specifying the right bus in the MP tables partially fixed the

Re: [m5-dev] interrupt messages

2008-09-04 Thread Steve Reinhardt
to implement things that seems obviously best. Gabe Quoting Steve Reinhardt [EMAIL PROTECTED]: The memory system doesn't do any segmentation. It will choke if you try and do a single access that spans cache blocks in cached memory. For uncached physical accesses, I don't know

Re: [m5-dev] snoop parameter on getDeviceAddrRanges

2008-09-07 Thread Steve Reinhardt
Any cacheable request will get snooped by any device that says it wants snoops (e.g., a cache or the cpu). Are you sure the request that's getting snooped is marked uncacheable? Steve On Sun, Sep 7, 2008 at 2:20 PM, Gabe Black [EMAIL PROTECTED] wrote: I'm still working on these interrupt

Re: [m5-dev] another microcode design decision

2008-09-17 Thread Steve Reinhardt
I'm a little confused... when you say microbranches are absolute, do you mean the target is an absolute offset within the sequence of uops generated by a macroinstruction? The sort of model that comes to mind based on your description is: - Use a bit somewhere *associated with the uop* that

Re: [m5-dev] another microcode design decision

2008-09-17 Thread Steve Reinhardt
On Wed, Sep 17, 2008 at 12:14 AM, Gabe Black [EMAIL PROTECTED] wrote: I think we're talking about mostly the same thing. The ROM bit would be global, but in the same sense that the PC is global. OK, I'll buy that... it's global in that there's one per thread context, but non-global in the

Re: [m5-dev] another microcode design decision

2008-09-18 Thread Steve Reinhardt
I see...the only reason I saw to switch to relative branches is that it avoids the need to distinguish between ROM and non-ROM targets. I guess the argument for their approach is that if your microcode flow is complex enough to require a branch then it's probably complex enough to need to come

Re: [m5-dev] another microcode design decision

2008-09-20 Thread Steve Reinhardt
of the combinational decoder, so it's like you get one instruction at that point. Either that one instruction does the trick, or you need to go to the ROM where a micropc conceptually exists. Gabe Quoting Steve Reinhardt [EMAIL PROTECTED]: I see...the only reason I saw to switch to relative

Re: [m5-dev] CPUID implementation

2008-09-20 Thread Steve Reinhardt
If it's that complicated, why not just do it in C++ inside of M5, and have a special microop that just calls that function and lets it do the dirty work? I don't think performance fidelity is an issue here, and even if it were, we could always just make that single microop take longer. Steve On

Re: [m5-dev] CPUID implementation

2008-09-20 Thread Steve Reinhardt
Collecting the necessary information in Python up front seems reasonable to me. As far as where the C++ code would go, it seems to me it could either be a method on the BaseCPU object or a global function in the x86 ISA namespace. The latter makes sense if we're trying not to pollute the CPU

Re: [m5-dev] header file loops

2008-09-21 Thread Steve Reinhardt
I think keeping the register index type as part of the ISA makes sense: in almost all conceivable cases a uint8_t is adequate, and when you're packing several of these in each StaticInst it can really add up to poor cache utilization, but forcing all future architectures to have at most 256 regs

Re: [m5-dev] IsOn using a vector

2008-09-23 Thread Steve Reinhardt
at some point but my vote would be to go with bitset since it sounds like that would get us where we'd want to be. Gabe Quoting Steve Reinhardt [EMAIL PROTECTED]: I thought vectorbool was supposed to be a space-optimized bit vector. I think there are two things going on here

Re: [m5-dev] ISA specific decoder state

2008-09-23 Thread Steve Reinhardt
On Tue, Sep 23, 2008 at 8:51 PM, Gabe Black [EMAIL PROTECTED] wrote: I'm mostly concerned about handling the interrupt, not actually handling the fault from fetching. There are sort of two dimensions to this problem. First is that there isn't really a good way to tell when a macroop ends

Re: [m5-dev] trouble with get mixie inorder model to compile

2008-09-26 Thread Steve Reinhardt
I'm not sure how it's supposed to work (perhaps only Korey can answer that), but I think the basic problem here is that memAccFlags is only defined in the Memory subclass of MipsStaticInst while what you are trying to dereference is a pointer to the base StaticInst class. Steve On Fri, Sep 26,

Re: [m5-dev] changeset in m5: Use logical operator instead of bitwise operato...

2008-09-26 Thread Steve Reinhardt
Why the double negative (!yield_mask != 0)? Seems like this should either be !yield_mask or yield_mask == 0, but not something in between... Steve On Fri, Sep 26, 2008 at 3:29 PM, Nathan Binkert [EMAIL PROTECTED] wrote: changeset eb5664be6075 in /z/repo/m5 details:

Re: [m5-dev] changeset in m5: Use logical operator instead of bitwise operato...

2008-09-26 Thread Steve Reinhardt
Your response was not without humor... On Fri, Sep 26, 2008 at 4:38 PM, nathan binkert [EMAIL PROTECTED] wrote: I don't disagree. 2008/9/26 Steve Reinhardt [EMAIL PROTECTED]: Why the double negative ___ m5-dev mailing list m5-dev@m5sim.org http

Re: [m5-dev] changeset in m5: style: Make a style pass over the whole arch/al...

2008-09-27 Thread Steve Reinhardt
I thought that we had agreed to always use braces for control structures (for, if, while, etc.) since that makes it easier to add/remove lines without worrying about adding/removing braces too. I don't see it mentioned either way on the coding style page, but I know I've developed the habit of

Re: [m5-dev] changeset in m5: style: Make a style pass over the whole arch/al...

2008-09-27 Thread Steve Reinhardt
On Sat, Sep 27, 2008 at 9:35 PM, nathan binkert [EMAIL PROTECTED] wrote: I think that sounds fine. Does no braces required also mean no braces allowed, or is that something left up to the implementers discretion? I think it should be optional rather than forbidden. I'd agree with

[m5-dev] Fwd: FW: changeset in m5: Make overriding port assignments in Python work,

2008-09-30 Thread Steve Reinhardt
-- Forwarded message -- From: Reinhardt, Steve [EMAIL PROTECTED] Date: Tue, Sep 30, 2008 at 7:16 AM Subject: FW: changeset in m5: Make overriding port assignments in Python work, To: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

Re: [m5-dev] microcode plan of record

2008-09-30 Thread Steve Reinhardt
Great, glad you guys were able to do that. There will be a new flag on static insts which will indicate whether or not they leave the context of the current macroop on faults. Is this flag for microops or macroops or both? Is this feature required only for the optimization cases you

Re: [m5-dev] help with patch repository

2008-10-06 Thread Steve Reinhardt
Did you do an hg mv rename on the patch file? What happens if you try creating both files (old and new) and then doing an hg rm on the one you don't want? Steve On Mon, Oct 6, 2008 at 1:59 AM, Gabe Black [EMAIL PROTECTED] wrote: I'm trying to commit my patch repository and push it up to

Re: [m5-dev] changeset in m5: X86: Rename the PC device to Pc.

2008-10-11 Thread Steve Reinhardt
The official coding style is that names that are acronyms should be all upper case (e.g., CPU): http://m5sim.org/wiki/index.php/Coding_Style#Naming Again, not that I have such a strong opinion either way, just seeking consistency... Steve On Sat, Oct 11, 2008 at 2:26 AM, Gabe Black [EMAIL

Re: [m5-dev] changeset in m5: X86: Rename the PC device to Pc.

2008-10-11 Thread Steve Reinhardt
well. Sorry about that. Gabe Steve Reinhardt wrote: The official coding style is that names that are acronyms should be all upper case (e.g., CPU): http://m5sim.org/wiki/index.php/Coding_Style#Naming Again, not that I have such a strong opinion either way, just seeking consistency

Re: [m5-dev] changeset in m5: Create a message port for sending messages as a...

2008-10-13 Thread Steve Reinhardt
Hi Gabe, I haven't looked at all the code surrounding this in detail, but I think this is unnecessary... packets really are messages (though up to now they've all been coherence messages), and the idea behind Port objects is that in the common case a MemObject should have a dedicated Port

Re: [m5-dev] cpu vs thread vs contexts

2008-10-24 Thread Steve Reinhardt
I'd add that even for stats the cpu ID shouldn't be used much... the stats that are associated with the cpu object will automatically be associated with the correct cpu, and for just about everything outside the cpu object that cares about tracking where something came from (e.g., caches) we

Re: [m5-dev] cpu vs thread vs contexts

2008-10-24 Thread Steve Reinhardt
yea: http://m5sim.org/wiki/index.php/Coding_Style#Naming The question is, is ID an acronym or an abbreviation? Technically it's the latter but people seem to treat it as the former... On Fri, Oct 24, 2008 at 3:42 PM, Korey Sewell [EMAIL PROTECTED] wrote: i think the convention is any acronym

Re: [m5-dev] semantics of translating unaligned accesses

2008-10-27 Thread Steve Reinhardt
There's also the possibility that these accesses could be atomic, right? On Mon, Oct 27, 2008 at 5:33 PM, Gabe Black [EMAIL PROTECTED] wrote: In the atomic simple CPU, they're broken up across the CPU's peers blocksize aligned boundaries by the CPU and done as x different accesses, usually 1

Re: [m5-dev] semantics of translating unaligned accesses

2008-10-27 Thread Steve Reinhardt
being atomic, so for x86 at least atomicity is a larger, separate problem. I'm not sure about that though. I'll see if I can find anything in the manuals. Gabe Steve Reinhardt wrote: There's also the possibility that these accesses could be atomic, right? On Mon, Oct 27, 2008 at 5:33 PM, Gabe

Re: [m5-dev] semantics of translating unaligned accesses

2008-10-30 Thread Steve Reinhardt
lines we're ensuring all the atomicity Intel does. The only tricky part is if something about the translation changes halfway through an instruction, but I don't think there are any guarantees about what's supposed to happen then anyway. Gabe Steve Reinhardt wrote: OK... so if we have

Re: [m5-dev] early failing store conditional dcache_pkt

2008-11-02 Thread Steve Reinhardt
You need to always call completeAcc() because it may do something necessary... in the case of store conditional, it updates the destination register that indicates to the program whether the store succeeded or not. completeAcc() gets this information out of the packet, so that's why you need to

Re: [m5-dev] early failing store conditional dcache_pkt

2008-11-03 Thread Steve Reinhardt
know what they can/can't expect, etc. Gabe Steve Reinhardt wrote: You need to always call completeAcc() because it may do something necessary... in the case of store conditional, it updates the destination register that indicates to the program whether the store succeeded

Re: [m5-dev] CMP using EIO traces

2008-11-04 Thread Steve Reinhardt
It's definitely a bug... it used to work. I wonder if it has something to do with migrating towards a more realistic paging model for SE mode (though that happened quite a while ago---August 2007 according to hg---and if that was totally broken I'm surprised no one noticed it yet). I'd take a

Re: [m5-dev] encumbered: fix multicore eio.

2008-11-04 Thread Steve Reinhardt
EIO is Alpha only right now and will almost certainly remain so... not because you couldn't port it to other ISAs, but if we decided we did want to have an ISA-independent EIO-like capability we'd almost certainly develop something else from scratch. The actual EIO code is really there only for

  1   2   3   4   5   6   7   8   9   10   >