Re: [m5-dev] changeset in m5: slicc: fixed MI_example bug. The directory was...
Derek,
I'd like to request that you insert newlines such that your comments
wrap at 80 columns.
Thanks,
Nate
On Wed, Jul 8, 2009 at 7:23 AM, Derek Howerd...@cs.wisc.edu wrote:
changeset 57650468aff1 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=57650468aff1
description:
slicc: fixed MI_example bug. The directory wasn't deallocating the
TBE, leading to a leak. Also increased the default max TBE size to 256 to
allow memtest to pass the regression.
diffstat:
2 files changed, 7 insertions(+), 7 deletions(-)
src/mem/protocol/MI_example-dir.sm | 12 ++--
src/mem/ruby/config/defaults.rb | 2 +-
diffs (82 lines):
diff -r 553a34ccd03b -r 57650468aff1 src/mem/protocol/MI_example-dir.sm
--- a/src/mem/protocol/MI_example-dir.sm Wed Jul 08 00:34:40 2009 -0500
+++ b/src/mem/protocol/MI_example-dir.sm Wed Jul 08 08:40:32 2009 -0500
@@ -528,14 +528,15 @@
transition(I, DMA_WRITE, ID_W) {
- dw_writeDMAData;
-// da_sendDMAAck;
+ v_allocateTBE;
qw_queueMemoryWBRequest_partial;
p_popIncomingDMARequestQueue;
}
transition(ID_W, Memory_Ack, I) {
+ dwt_writeDMADataFromTBE;
da_sendDMAAck;
+ w_deallocateTBE;
l_popMemQueue;
}
@@ -548,7 +549,7 @@
drp_sendDMAData;
c_clearOwner;
a_sendWriteBackAck;
- // d_deallocateDirectory;
+ d_deallocateDirectory;
i_popIncomingRequestQueue;
}
@@ -561,7 +562,6 @@
transition(M_DWR, PUTX, M_DWRI) {
qw_queueMemoryWBRequest_partialTBE;
c_clearOwner;
- w_deallocateTBE;
i_popIncomingRequestQueue;
}
@@ -570,6 +570,7 @@
l_sendWriteBackAck;
da_sendDMAAck;
w_deallocateTBE;
+ d_deallocateDirectory;
l_popMemQueue;
}
@@ -583,7 +584,6 @@
c_clearOwner;
v_allocateTBEFromRequestNet;
l_queueMemoryWBRequest;
- d_deallocateDirectory;
i_popIncomingRequestQueue;
}
@@ -591,6 +591,7 @@
w_writeDataToMemoryFromTBE;
l_sendWriteBackAck;
w_deallocateTBE;
+ d_deallocateDirectory;
l_popMemQueue;
}
@@ -601,7 +602,6 @@
transition(I, PUTX_NotOwner, I) {
b_sendWriteBackNack;
- d_deallocateDirectory;
i_popIncomingRequestQueue;
}
diff -r 553a34ccd03b -r 57650468aff1 src/mem/ruby/config/defaults.rb
--- a/src/mem/ruby/config/defaults.rb Wed Jul 08 00:34:40 2009 -0500
+++ b/src/mem/ruby/config/defaults.rb Wed Jul 08 08:40:32 2009 -0500
@@ -12,7 +12,7 @@
default_param :buffer_size, Integer, 32
# added by SS for TBE
- default_param :number_of_TBEs, Integer, 128
+ default_param :number_of_TBEs, Integer, 256
default_param :recycle_latency, Integer, 10
end
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby FAILED! I'm guessing that this changed because of the tweaks Derek has made to the MI_example protocol. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Gem5 configuration
- 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 can't assume too much about what that other object is prepared to do though. If you need to do something that relies on the other object having been through init(), you need to do it in startup(). Note that this means you can't have circular parameter dependencies. Basically if you have two objects A and B that need to know about each other (other than being connected via a port), there's a special relationship, and one of them will have a register method. So for example A will get a pointer to B, but then in A's constructor or init() method it will call B-registerA() to say hey B, I'm your A. Are you sure that this is guaranteed? I know we've gone back and forth about this and circular dependencies and whether we support them. Maybe we don't support them yet. (Though we could) As always, the source is the ultimate guide; since Nate moved a lot of this into python I had to do some searching to find it myself. See src/python/sim/simulate.py and realize that a number of the functions that get called there are actually C++ functions wrapped via SWIG. Construction and init() are called from m5.instantiate() startup() is called the first time that simulate() is called. If anyone (Nate?) has some more specific guidelines on how things should be split conceptually between the constructor, init(), and startup() please speak up. I think that the general rule of thumb should be that constructors can use *non* SimObject parameters. init() should use SimObject parameters. I could create a proxy object to wrap SimObject parameters to assert() that things are done correctly. startup() should be for stuff that is dependent on happening *after* resume from checkpoint. The most common example of this is if you're scheduling an event. curTick is set to the checkpoint tick after init() but before startup(), so you should schedule all events in startup(). This will likely become more important when we parallelize. I could certainly do some asserting when this starts to matter. We really should get this stuff onto the wiki. Steve, if you get a skeleton, I can flesh it out. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby FAILED! Derek, M5 regressions not only ensure that the program doesn't crash, but they ensure that the stats don't change either. So, this stat likely failed because the stats changed somewhat due to your recent fix. Basically you need to run the test look at the changes if they're right, re-run the test with update_ref=True added to the SCons command line (it shouldn't actually run again if nothing changed). This will copy new reference files to the tests directory and you should then commit them. Make sense? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
Are there any options passed to memtest-ruby in the regression? If I run the test as: scons build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby then the memtest program appears to run in an infinite loop. Are you sure it's an infinite loop? It does take nearly 10 minutes to run on a fast, new machine. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: Tester update
Polina,
Please be very careful when you update files. This update changed the
license text on a bunch of files. Please put the license text back the
way it was. If there are other licenses you changed in other commits,
can you please fix those as well?
Nate
On Thu, Jul 16, 2009 at 1:38 PM, pdud...@gmail.com wrote:
changeset bd813379f121 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=bd813379f121
description:
Tester update
diffstat:
25 files changed, 1145 insertions(+), 969 deletions(-)
src/mem/ruby/common/Driver.hh | 17 -
src/mem/ruby/tester/DetermGETXGenerator.cc | 120 +
src/mem/ruby/tester/DetermGETXGenerator.hh | 92 ++---
src/mem/ruby/tester/DetermInvGenerator.cc | 102 +++
src/mem/ruby/tester/DetermInvGenerator.hh | 91 ++---
src/mem/ruby/tester/DetermSeriesGETSGenerator.cc | 91 ++---
src/mem/ruby/tester/DetermSeriesGETSGenerator.hh | 90 ++---
src/mem/ruby/tester/DeterministicDriver.cc | 109 +++
src/mem/ruby/tester/DeterministicDriver.hh | 102 +++
src/mem/ruby/tester/Driver_Tester.cc | 44
src/mem/ruby/tester/Driver_Tester.hh | 82
src/mem/ruby/tester/EventQueue_Tester.hh | 118
src/mem/ruby/tester/Global_Tester.hh | 74
src/mem/ruby/tester/RaceyDriver.cc | 87 ++---
src/mem/ruby/tester/RaceyDriver.hh | 92 ++---
src/mem/ruby/tester/RaceyPseudoThread.cc | 67 +++
src/mem/ruby/tester/RaceyPseudoThread.hh | 49 ++---
src/mem/ruby/tester/SpecifiedGenerator.cc | 79 +---
src/mem/ruby/tester/SpecifiedGenerator.hh | 88 ++---
src/mem/ruby/tester/Tester_Globals.hh | 66 +++
src/mem/ruby/tester/main.cc | 79 +---
src/mem/ruby/tester/main.hh | 84 ++---
src/mem/ruby/tester/test_framework.cc | 203 +++---
src/mem/ruby/tester/test_framework.hh | 84 ++---
src/mem/rubymem.cc | 4
diffs (truncated from 3057 to 300 lines):
diff -r ceb2e719e36c -r bd813379f121 src/mem/ruby/common/Driver.hh
--- a/src/mem/ruby/common/Driver.hh Mon Jul 13 18:39:32 2009 -0500
+++ b/src/mem/ruby/common/Driver.hh Wed Jul 15 10:46:22 2009 -0500
@@ -40,13 +40,8 @@
#include mem/ruby/common/Global.hh
#include mem/ruby/common/Consumer.hh
#include mem/ruby/system/NodeID.hh
-#include mem/protocol/CacheRequestType.hh
+#include mem/ruby/common/Address.hh
-class RubySystem;
-class SubBlock;
-class Address;
-class MachineID;
-class SimicsHypervisor;
class Driver {
public:
@@ -58,15 +53,12 @@
// Public Methods
virtual void get_network_config() {}
- virtual void dmaHitCallback() = 0;
- virtual void hitCallback(NodeID proc, SubBlock data, CacheRequestType
type, int thread) = 0; // Called by sequencer
- virtual void conflictCallback(NodeID proc, SubBlock data,
CacheRequestType type, int thread) { assert(0); }; // Called by sequencer
+ virtual void dmaHitCallback() {};
+ virtual void hitCallback(int64_t id) = 0; // Called by sequencer
+ virtual void go() = 0;
virtual integer_t getInstructionCount(int procID) const { return 1; }
virtual integer_t getCycleCount(int procID) const { return 1; }
virtual void addThreadDependency(int procID, int requestor_thread, int
conflict_thread) const { assert(0);}
- virtual int inTransaction(int procID, int thread ) const{
- cout Driver.hh inTransaction endl;
-return false; } //called by Sequencer
virtual void printDebug(){} //called by Sequencer
virtual void printStats(ostream out) const = 0;
@@ -74,7 +66,6 @@
virtual void printConfig(ostream out) const = 0;
- //virtual void abortCallback(NodeID proc){}
virtual integer_t readPhysicalMemory(int procID, physical_address_t address,
int len ){ ASSERT(0); return 0; }
diff -r ceb2e719e36c -r bd813379f121
src/mem/ruby/tester/DetermGETXGenerator.cc
--- a/src/mem/ruby/tester/DetermGETXGenerator.cc Mon Jul 13 18:39:32
2009 -0500
+++ b/src/mem/ruby/tester/DetermGETXGenerator.cc Wed Jul 15 10:46:22
2009 -0500
@@ -1,31 +1,58 @@
/*
- * Copyright (c) 1999-2008 Mark D. Hill and David A. Wood
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are
- * met: redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer;
- * redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution;
- * neither the
Re: [m5-dev] changeset in m5: 1. Got rid of unused functions in DirectoryMemory
Polina,
In general, please don't put unrelated changes into a single
changeset. Also, when you put together a commit message, Can you make
the first line be a summary of the commit and subsequent lines go into
more detail? This is helpful when using tools such as hg log which
by default just prints out the first line of each commit message so
you can scroll through changes very quickly. There are a lot of tools
that work that way.
(Sorry to be nitpicky)
Thanks!
Nate
On Thu, Jul 16, 2009 at 1:38 PM, pdud...@gmail.com wrote:
changeset 79464d8a4d2f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=79464d8a4d2f
description:
1. Got rid of unused functions in DirectoryMemory
2. Reintroduced RMW_Read and RMW_Write
3. Defined -2 in the Sequencer as well as made a note about mandatory
queue
Did not address the issues in the slicc because remaking the atomics
altogether to allow
multiple processors to issue atomic requests at once
diffstat:
6 files changed, 31 insertions(+), 22 deletions(-)
src/mem/ruby/common/DataBlock.hh | 18 --
src/mem/ruby/libruby.cc | 8
src/mem/ruby/libruby.hh | 4 +++-
src/mem/ruby/recorder/TraceRecord.cc | 2 +-
src/mem/ruby/system/DMASequencer.cc | 2 ++
src/mem/ruby/system/Sequencer.cc | 19 +--
diffs (170 lines):
diff -r 390fefc98e2b -r 79464d8a4d2f src/mem/ruby/common/DataBlock.hh
--- a/src/mem/ruby/common/DataBlock.hh Mon Jul 13 12:50:10 2009 -0500
+++ b/src/mem/ruby/common/DataBlock.hh Mon Jul 13 17:22:29 2009 -0500
@@ -56,9 +56,6 @@
uint8 getByte(int whichByte) const;
const uint8* getData(int offset, int len) const;
void setByte(int whichByte, uint8 data);
- const uint8* getBlock() const;
- uint8* copyData(uint8* dest, int offset, int size) const;
- void setBlock(uint8* data) { setData(data, 0,
RubySystem::getBlockSizeBytes()); }
void setData(uint8* data, int offset, int len);
void copyPartial(const DataBlock dblk, int offset, int len);
bool equal(const DataBlock obj) const;
@@ -149,21 +146,6 @@
setData(dblk.m_data[offset], offset, len);
}
-inline
-const uint8* DataBlock::getBlock() const
-{
- return m_data;
-}
-
-inline
-uint8* DataBlock::copyData(uint8* dest, int offset, int size) const
-{
- assert(offset + size = RubySystem::getBlockSizeBytes());
- memcpy(dest, m_data + offset, size);
- return dest;
-}
-
-
// *** Definitions ***
// Output operator definition
diff -r 390fefc98e2b -r 79464d8a4d2f src/mem/ruby/libruby.cc
--- a/src/mem/ruby/libruby.cc Mon Jul 13 12:50:10 2009 -0500
+++ b/src/mem/ruby/libruby.cc Mon Jul 13 17:22:29 2009 -0500
@@ -24,6 +24,10 @@
return Locked_Read;
case RubyRequestType_Locked_Write:
return Locked_Write;
+ case RubyRequestType_RMW_Read:
+ return RMW_Read;
+ case RubyRequestType_RMW_Write:
+ return RMW_Write;
case RubyRequestType_NULL:
default:
assert(0);
@@ -43,6 +47,10 @@
return RubyRequestType_Locked_Read;
else if (str == Locked_Write)
return RubyRequestType_Locked_Write;
+ else if (str == RMW_Read)
+ return RubyRequestType_RMW_Read;
+ else if (str == RMW_Write)
+ return RubyRequestType_RMW_Write;
else
assert(0);
return RubyRequestType_NULL;
diff -r 390fefc98e2b -r 79464d8a4d2f src/mem/ruby/libruby.hh
--- a/src/mem/ruby/libruby.hh Mon Jul 13 12:50:10 2009 -0500
+++ b/src/mem/ruby/libruby.hh Mon Jul 13 17:22:29 2009 -0500
@@ -12,7 +12,9 @@
RubyRequestType_LD,
RubyRequestType_ST,
RubyRequestType_Locked_Read,
- RubyRequestType_Locked_Write
+ RubyRequestType_Locked_Write,
+ RubyRequestType_RMW_Read,
+ RubyRequestType_RMW_Write
};
enum RubyAccessMode {
diff -r 390fefc98e2b -r 79464d8a4d2f src/mem/ruby/recorder/TraceRecord.cc
--- a/src/mem/ruby/recorder/TraceRecord.cc Mon Jul 13 12:50:10 2009 -0500
+++ b/src/mem/ruby/recorder/TraceRecord.cc Mon Jul 13 17:22:29 2009 -0500
@@ -50,7 +50,7 @@
if (m_type == RubyRequestType_Locked_Read) {
m_type = RubyRequestType_ST;
}
- if (m_type == RubyRequestType_Locked_Write) {
+ else if (m_type == RubyRequestType_Locked_Write) {
m_type = RubyRequestType_ST;
}
}
diff -r 390fefc98e2b -r 79464d8a4d2f src/mem/ruby/system/DMASequencer.cc
--- a/src/mem/ruby/system/DMASequencer.cc Mon Jul 13 12:50:10 2009 -0500
+++ b/src/mem/ruby/system/DMASequencer.cc Mon Jul 13 17:22:29 2009 -0500
@@ -48,6 +48,8 @@
case RubyRequestType_IFETCH:
case RubyRequestType_Locked_Read:
case RubyRequestType_Locked_Write:
+ case RubyRequestType_RMW_Read:
+ case RubyRequestType_RMW_Write:
assert(0);
}
diff -r 390fefc98e2b -r 79464d8a4d2f src/mem/ruby/system/Sequencer.cc
--- a/src/mem/ruby/system/Sequencer.cc Mon Jul 13 12:50:10 2009 -0500
+++ b/src/mem/ruby/system/Sequencer.cc Mon Jul 13 17:22:29 2009
Re: [m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby FAILED! The memory tester has failed again. Can someone check it out? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] missing emails
I don't think I got one. It could be a size limit. You can check the archive to see if it made it there. What's the size of the diff? Nate On Sat, Jul 18, 2009 at 4:04 PM, Gabe Blackgbl...@eecs.umich.edu wrote: Are you a moderator for the list? Maybe the attachment was too big and you were being asked to approve it? Gabe Gabe Black wrote: No, although I asked Lisa if she'd seen the emails and she hadn't. I never saw your reply either. I checked my spam folder, but it's possible it got stopped before it even got to me. Gabe Steve Reinhardt wrote: 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 Blackgbl...@eecs.umich.edu wrote: I've tried sending a patch to this list three times, twice with hg and once manually, and all three have gone missing. Does anyone know what might have happened to them? Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] a few questions
[responding on m5-dev since it's a better place to deal with this.]
1) How can I build a fast libm5? i.e. with a -O3 compile flag
Just replace libm5_debug.so with libm5_opt.so. There's also
libm5_fast.so that has all of the debugging stuff #ifdef'd out.
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 for that yet, but I will work on getting
something together as soon as I can. Basically, the right thing to do
is have a RubyMemory for each protocol compiled into the m5 library.
Then add a protocol= parameter to the SimObject to pick the protocol
that we want. To do this correctly requires some SCons magic to
compile things multiple times, each with a different protocol. So we
can link all of them in at once though, we'll need to add something
like namespace PROTOCOL { } around everything (where PROTOCOL is the
#defined protocol name. Does this make sense. Anyone have better
ideas for how to do this? Steve?
3) Somayeh still doesn't have an svn account to check in changes. Can
you take care of that?
I'll try to do that tonight or tomorrow.
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: Tracing: Add accessors so tracers can get at da...
No big deal, but we decided a while ago that if you have accessors, it
should be:
int _foo;
int foo() const { return _foo; }
void foo(int val) { _foo = val; }
instead of:
int foo;
int getFoo() const { return foo; }
void setFoo(int val) { foo = val; }
On Mon, Jul 20, 2009 at 12:48 AM, Gabe Blackgbl...@eecs.umich.edu wrote:
changeset a71fd8e252b7 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a71fd8e252b7
description:
Tracing: Add accessors so tracers can get at data in trace records.
diffstat:
1 file changed, 22 insertions(+)
src/sim/insttracer.hh | 22 ++
diffs (32 lines):
diff -r a17979b4e1ea -r a71fd8e252b7 src/sim/insttracer.hh
--- a/src/sim/insttracer.hh Sun Jul 19 23:51:47 2009 -0700
+++ b/src/sim/insttracer.hh Sun Jul 19 23:54:31 2009 -0700
@@ -129,6 +129,28 @@
{ cp_seq = seq; cp_seq_valid = true; }
virtual void dump() = 0;
+
+ public:
+ Tick getWhen() { return when; }
+ ThreadContext *getThread() { return thread; }
+ StaticInstPtr getStaticInst() { return staticInst; }
+ Addr getPC() { return PC; }
+ StaticInstPtr getMacroStaticInst() { return macroStaticInst; }
+ MicroPC getUPC() { return upc; }
+ bool getMisspeculating() { return misspeculating; }
+
+ Addr getAddr() { return addr; }
+ bool getAddrValid() { return addr_valid; }
+
+ uint64_t getIntData() { return data.as_int; }
+ double getFloatData() { return data.as_double; }
+ int getDataStatus() { return data_status; }
+
+ InstSeqNum getFetchSeq() { return fetch_seq; }
+ bool getFetchSeqValid() { return fetch_seq_valid; }
+
+ InstSeqNum getCpSeq() { return cp_seq; }
+ bool getCpSeqValid() { return cp_seq_valid; }
};
class InstTracer : public SimObject
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] m5 web cross-reference
[Sorry, Alex hit send last time] Awesome! As a note, I was looking into this a little bit and there was some stuff about tomcat 6 not working. I'm not sure if this is still true, but just in case. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Scons with SLICC
I've noticed that scons creates and runs the SLICC parser every time you build. Is this absolutely necessary? It seems to slow down the build quite a bit, especially when recompiling a minor change. This shouldn't be happening. Does this happen whether or not you make any changes? Can you give me some sort of test case to reproduce them. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] repository access
As we're adding users, we decided that it is a pain to give everyone a shell account on daystrom, so we're switching to the shared ssh mechanism of access control for committing to the repository. We're doing this for several reasons: 1) ease of management 2) much more secure 3) easier user experience (with an ssh key and the ssh agent, you only type your passphrase once (how nice!)) Instead of having one unix user account per committer, all we need is an ssh key for each committer and we all share a single unix user account. repository paths that used to look like this: ssh://m5sim.org//repo/repo now look like this: ssh://h...@m5sim.org/repo if you're using http to pull, nothing changes. Everyone will need to edit their .hg/hgrc files for every repository that points to daystrom as a parent. I've gathered all of the ssh keys that I could find on daystrom and installed them. Here are the people I've found keys for. If you're listed as admin, you can administer the list of committers, if you're listed as a committer, you can push, if you're listed as inactive, it's because I haven't seen a commit from you in a long time and I'd like to disable your access until such time that you'd actually use it. (Test things out and make sure things work) ali_saidi, nate_binkert, steve_reinhardt, gabe_black (admin, committer) rick_strong, lisa_hsu, korey_sewell, kevin_lim (committer) clint_smullen, steve_hines, trevor_mudge (inactive) I don't have a key for these people: Arkaprava Basu, Brad Beckmann, Geoff Blake, Christos Kozyrakis, Daniel Sanchez, David Wood, Derek Hower, Dan Gibson, Mark Hill, Miles Childs Kaufmann, Polina Dudnik, Ronald George Dreslinski Jr, Somayeh Sardashti, Cong Wang For those of you that don't plan on committing any time soon, we'll just disable your account until you plan to start committing (it's more secure that way anyway). I'm going to disable non-admin user accounts in a few days. If you want to maintain uninterrupted commit access, please send me your ssh *PUBLIC* key before then. For those of you that don't know what an ssh key is, please use google (you should also check out the ssh agent). This website seems to do a decent job of explaining things: http://sial.org/howto/openssh/publickey-auth/ Any questions? (Please don't make me respond with RTFM.) Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] MIPS_SE compile error
Korey, can you please comment on this? I'd like to commit a fix since
I'm running a compiler that fails on this as well.
Nate
On Wed, Jul 29, 2009 at 2:48 PM, Vince Weavervi...@csl.cornell.edu wrote:
Hello
not sure if this is the proper place to send packages, but here it goes
currently building for MIPS_SE fails. It looks like a = instead of a ==
error, but the code is pretty dense so I can't tell if it's trying to be
overly clever.
patch attached below.
Vince
diff -r b35ef789e6f6 src/arch/mips/mt.hh
--- a/src/arch/mips/mt.hh Wed Jul 29 00:35:49 2009 -0700
+++ b/src/arch/mips/mt.hh Wed Jul 29 17:42:04 2009 -0400
@@ -118,7 +118,7 @@
tc-readRegOtherThread(MISCREG_TC_BIND + Ctrl_Base_DepTag, tid);
TCBindReg tcBind = tc-readMiscRegNoEffect(MISCREG_TC_BIND);
- if (tidTCBind.curVPE = tcBind.curVPE) {
+ if (tidTCBind.curVPE == tcBind.curVPE) {
TCStatusReg tidTCStatus =
tc-readRegOtherThread(MISCREG_TC_STATUS +
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: compile: fix accidental conversion of == into =
changeset 58e3056d918e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=58e3056d918e
description:
compile: fix accidental conversion of == into =
diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
src/arch/mips/mt.hh |2 +-
diffs (12 lines):
diff -r 727622fa50e5 -r 58e3056d918e src/arch/mips/mt.hh
--- a/src/arch/mips/mt.hh Wed Jul 29 22:24:00 2009 -0700
+++ b/src/arch/mips/mt.hh Thu Jul 30 17:42:57 2009 -0700
@@ -118,7 +118,7 @@
tc-readRegOtherThread(MISCREG_TC_BIND + Ctrl_Base_DepTag, tid);
TCBindReg tcBind = tc-readMiscRegNoEffect(MISCREG_TC_BIND);
-if (tidTCBind.curVPE = tcBind.curVPE) {
+if (tidTCBind.curVPE == tcBind.curVPE) {
TCStatusReg tidTCStatus =
tc-readRegOtherThread(MISCREG_TC_STATUS +
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] GEM5 Issues
I have no plans to fix any of this, but please do not just check in fixes without sending out patches for review.I'm particularly interested in the first two. For the generated protocol code, are you trying to simultaneously compile multiple protocols into the same binary or just trying to make it so you don't have to recompile if you switch between the two. I don't know if you can do the latter without doing the former because of how scons does dependencies. I can say that I do know how to do the former. For the error messages, I see no reason not to fix this now. Nate Tushar and I have noticed a few issues with GEM5 and we were wondering if anyone had plans to fix them. If not, we'll go ahead and check in fixes to the global repository. I just want to make sure we're not stepping on anyone's toes. - Fix SLICC so that protocol generated files are created in separate protocol specific folders. Currently they are created in the same mem/protocol folder overwriting older files (eg. build/ALPHA_SE/mem/protocol//ControllerFactory.cc). - Fully integrate SLICC parsing errors into scons. Right now the error messages don't give any useful info. Should we hold off on fixing this until SLICCer is added to GEM5? - Support broadcast protocols with NetDest ruby functions. I notices that one of Derek's recent checkins removed all the NetDest functions in RubySlicc_ComponentMapping.hh. Most of them were lot old, protocol specific, and needed to go. However there were a few general ones that are needed by any broadcast based protocol. Are there plans to add these back into the tree? - I appreciate that a lot of the controller assumptions on the ruby side have been removed. However, it appears that Ruby now assumes a DMA controller is present. Is there plans to clean this up. Again, we're happy to fix this stuff up ourselves. I just want to be sure there aren't plans already in progress. Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: Rename internal Request fields to start with '_'.
Very awesome. I was tempted to do this a number of times. I'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 Reinhardtsteve.reinha...@amd.com wrote:
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 as the fields.
This is also a first step to switching the accessors over to
our new standard, e.g., getVaddr() - vaddr().
diffstat:
1 file changed, 58 insertions(+), 56 deletions(-)
src/mem/request.hh | 114 ++--
diffs (292 lines):
diff -r e46754b929ca -r 50125d42559c src/mem/request.hh
--- a/src/mem/request.hh Fri Jul 31 10:40:42 2009 -0400
+++ b/src/mem/request.hh Sat Aug 01 22:50:10 2009 -0700
@@ -132,17 +132,17 @@
* The physical address of the request. Valid only if validPaddr
* is set.
*/
- Addr paddr;
+ Addr _paddr;
/**
* The size of the request. This field must be set when vaddr or
* paddr is written via setVirt() or setPhys(), so it is always
* valid as long as one of the address fields is valid.
*/
- int size;
+ int _size;
/** Flag structure for the request. */
- Flags flags;
+ Flags _flags;
/** Private flags for field validity checking. */
PrivateFlags privateFlags;
@@ -155,15 +155,15 @@
Tick _time;
/** The address space ID. */
- int asid;
+ int _asid;
/** The virtual address of the request. */
- Addr vaddr;
+ Addr _vaddr;
/**
* Extra data for the request, such as the return value of
* store conditional or the compare value for a CAS. */
- uint64_t extraData;
+ uint64_t _extraData;
/** The context ID (for statistics, typically). */
int _contextId;
@@ -171,10 +171,13 @@
int _threadId;
/** program counter of initiating access; for tracing/debugging */
- Addr pc;
+ Addr _pc;
public:
- /** Minimal constructor. No fields are initialized. */
+ /** Minimal constructor. No fields are initialized.
+ * (Note that _flags and privateFlags are cleared by Flags
+ * default constructor.)
+ */
Request()
{}
@@ -218,23 +221,23 @@
* allocated Request object.
*/
void
- setPhys(Addr _paddr, int _size, Flags _flags, Tick time)
+ setPhys(Addr paddr, int size, Flags flags, Tick time)
{
- assert(_size = 0);
- paddr = _paddr;
- size = _size;
+ assert(size = 0);
+ _paddr = paddr;
+ _size = size;
_time = time;
- flags.clear(~STICKY_FLAGS);
- flags.set(_flags);
+ _flags.clear(~STICKY_FLAGS);
+ _flags.set(flags);
privateFlags.clear(~STICKY_PRIVATE_FLAGS);
privateFlags.set(VALID_PADDR|VALID_SIZE);
}
void
- setPhys(Addr _paddr, int _size, Flags _flags)
+ setPhys(Addr paddr, int size, Flags flags)
{
- setPhys(_paddr, _size, _flags, curTick);
+ setPhys(paddr, size, flags, curTick);
}
/**
@@ -242,18 +245,17 @@
* allocated Request object.
*/
void
- setVirt(int _asid, Addr _vaddr, int _size, Flags _flags, Addr _pc)
+ setVirt(int asid, Addr vaddr, int size, Flags flags, Addr pc)
{
- assert(_size = 0);
- asid = _asid;
- vaddr = _vaddr;
- size = _size;
- flags = _flags;
- pc = _pc;
+ assert(size = 0);
+ _asid = asid;
+ _vaddr = vaddr;
+ _size = size;
+ _pc = pc;
_time = curTick;
- flags.clear(~STICKY_FLAGS);
- flags.set(_flags);
+ _flags.clear(~STICKY_FLAGS);
+ _flags.set(flags);
privateFlags.clear(~STICKY_PRIVATE_FLAGS);
privateFlags.set(VALID_VADDR|VALID_SIZE|VALID_PC);
}
@@ -265,10 +267,10 @@
* to guarantee that the size and flags are also set.
*/
void
- setPaddr(Addr _paddr)
+ setPaddr(Addr paddr)
{
assert(privateFlags.isSet(VALID_VADDR));
- paddr = _paddr;
+ _paddr = paddr;
privateFlags.set(VALID_PADDR);
}
@@ -280,14 +282,14 @@
{
assert(privateFlags.isSet(VALID_VADDR));
assert(privateFlags.noneSet(VALID_PADDR));
- assert(split_addr vaddr split_addr vaddr + size);
+ assert(split_addr _vaddr split_addr _vaddr + _size);
req1 = new Request;
*req1 = *this;
req2 = new Request;
*req2 = *this;
- req1-size = split_addr - vaddr;
- req2-vaddr = split_addr;
- req2-size = size - req1-size;
+ req1-_size = split_addr - _vaddr;
+ req2-_vaddr = split_addr;
+ req2-_size
Re: [m5-dev] changeset in m5: Fix setting of INST_FETCH flag for O3 CPU.
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, mode is read/write/execute. You're proposing figuring just execute, or all of it? I'm for the change if it's all of it, but the funny thing is that the command is only in the packet object, so you don't know by looking at a request object if it is a read or write. (Which actually seems pretty odd.) Also, is it always unambiguous how to map a command to read or write? (My guess is probably, but i'm just checking.) Finally, any ideas how Ruby will deal with any of this? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: X86: Fix segment override prefixes on instructi...
I finally fixed the bug that was making the init scripts segfault. Now fsck is segfaulting, I believe because it's using a bunch of unimplemented SIMD/SSE/3dnow/mmx instructions. These are ~ movss, ucomiss, xorps, cvtsi2ss divss, mulss, addss, cvtss2sd, cvttss2si, and cvtdq2ps up to the point it crashes. Since it takes a long time to get to the point of failure, I'm hoping somebody on the list knows of where I can find a test suite that exercises these instructions. I'd guess this sort of thing is more likely to exist than a general x86 test suite since it might be used to test an FP emulation library, for instance. qemu has a tests directory and in it, there seems to be a pretty substantial tester for opcodes at least half of those opcodes are listed. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: X86: Fix segment override prefixes on instructi...
I finally fixed the bug that was making the init scripts segfault. Now Oh, and by the way. This is awesome news! Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Scons cleaning
The command: scons -c does not appear to remove SLICC generated files in mem/protocol (nor does scons -c target). I think it would be helpful if it did to avoid confusion about whether or not you're looking at a recently generated file. How can this be done? I just checked and the only files that are left there are a bunch of autogenerated header files that essentially just link to other header files. These are not actually generated by slicc. Are these files a problem? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Python SLICC
So, maybe I'm crazy, but a whole bunch of things got me convinced to started converting SLICC to python. Before I go way too far, I want to see if any of the Wisc have any objections to this. Here are what I see as the benefits: 1) Use python's powerful formatting function + triple quoted strings to make the code generator something that humans can more easily follow. If people want, I can send examples. 2) Make it easier to hack on the generated code. This is basically because #1 makes life easier. This is important for things like moving to M5 style configuration. 3) Reduction of total code by 50-70%. This is just a rough guess, but it mostly comes from #1, being able to be more concise when working with containers, and just plain being able to say more in each line. 4) It should be easier to improve SLICC in the future (Derek, I can help port SLICCer). 5) Deal with the generated files problem in a simple way. I tried to hack on SLICC to get it to tell me what files it would generate from a protocol specification. That proved difficult (I worked on it for several hours) because of these formatting issues and general difficulty with extending SLICC. The end result was that I ported the SLICC grammar to python (using PLY it took an hour) and wrote a quick script that did this job for me. By converting everything to python, there'd be just one grammar to worry about. 6) I can get rid of those intermediate #includes that SCons generates 7) PLY (Python Lex-Yacc) rocks and is generally easier and a whole lot more fun to work with than lex/yacc 8) I can learn a lot about SLICC in the process. Downsides: 1) This will probably use two more days of my time. I spent a few hours at it and probably converted about 25% of the code already. 2) I could introduce new bugs. 3) Maybe my changes will be superseded by SLICCer. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Python SLICC
The initial step is to simply translate the C++ code to python. I plan to change nothing about the AST structure or anything like that. The end result should be files that can be diffed, though will likely need to be diffed ignoring all whitespace. Once this is shown to work, then we can look at cleaning stuff up. One of the major reasons to do this is that the generated code is so fragile. Also, having translated a fair chunk of the generated code, it would be nice if the code generator were more modular. I think this would be a lot easier to do in python. Nate As someone who is very familiar with how SLICC currently generates code, I'm little concerned about changing the core of GEMS but maybe I just need to understand what you are proposing in more detail. Sometimes SLICC generation bugs can be hard bugs to find and I would be leery of potentially break it. It might be a lot of work to debug. I would like to know more details about what you are proposing. Would SLICC maintain the same formatting rules and AST structure? Therefore, the only changes beyond the new parser are the ast and symbol files would be implemented in python instead of C++, right? If that is the case, then you can verify Python SLICC by simply diffing the new generated files with the old generated files. That would be nice test to use, especially if you could test it across a few different protocols. If Python SLICC allows us to get closer to a unified configuration system, then that is a major plus. I would like to know more details of exactly what path you are thinking of and how Python SLICC helps. Thanks, Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of nathan binkert Sent: Monday, August 03, 2009 8:29 PM To: M5 Developer List Subject: [m5-dev] Python SLICC So, maybe I'm crazy, but a whole bunch of things got me convinced to started converting SLICC to python. Before I go way too far, I want to see if any of the Wisc have any objections to this. Here are what I see as the benefits: 1) Use python's powerful formatting function + triple quoted strings to make the code generator something that humans can more easily follow. If people want, I can send examples. 2) Make it easier to hack on the generated code. This is basically because #1 makes life easier. This is important for things like moving to M5 style configuration. 3) Reduction of total code by 50-70%. This is just a rough guess, but it mostly comes from #1, being able to be more concise when working with containers, and just plain being able to say more in each line. 4) It should be easier to improve SLICC in the future (Derek, I can help port SLICCer). 5) Deal with the generated files problem in a simple way. I tried to hack on SLICC to get it to tell me what files it would generate from a protocol specification. That proved difficult (I worked on it for several hours) because of these formatting issues and general difficulty with extending SLICC. The end result was that I ported the SLICC grammar to python (using PLY it took an hour) and wrote a quick script that did this job for me. By converting everything to python, there'd be just one grammar to worry about. 6) I can get rid of those intermediate #includes that SCons generates 7) PLY (Python Lex-Yacc) rocks and is generally easier and a whole lot more fun to work with than lex/yacc 8) I can learn a lot about SLICC in the process. Downsides: 1) This will probably use two more days of my time. I spent a few hours at it and probably converted about 25% of the code already. 2) I could introduce new bugs. 3) Maybe my changes will be superseded by SLICCer. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Scons with SLICC
Here is an output from a build after nothing changes, where I have the parser print when it runs. Which parser? The lex/yacc one or the python one? If it's the former, I'll try to fix it. If it's the latter, that parser has to be run, otherwise SCons won't know what files are being generated. I can check to see if there is any real performance impact from doing that, and if so, I could store the list of files in an intermediate file and only regenerate that intermediate file if one of the .slicc or .sm files changes. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Scons with SLICC
Which parser? The lex/yacc one or the python one? The Python one. If it's the former, I'll try to fix it. If it's the latter, that parser has to be run, otherwise SCons won't know what files are being generated. I can check to see if there is any real performance impact from doing that, and if so, I could store the list of files in an intermediate file and only regenerate that intermediate file if one of the .slicc or .sm files changes. I'm confused...are both parser.yy and parser.py used? Yeah. Unfortunately. This is part of my motivation for porting slicc to python. Keeping two grammars up to date seems like a bad policy. Either I need to figure out how to hack what I've done into the C++ slicc or I think I should finish porting slicc to python. I'm personally leaning towards the latter for the reasons I've enumerated in the other e-mail. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Python SLICC
I hope you don't mind me asking, but why does the fragility of generated code matter? One should never modify generated code and only rarely look at it. I'm referring to the generator itself. It's pretty hard to follow what's going on, so if you want to modify the generator itself, you need to be really careful about it. I'm interested to hear your ideas about how moving SLICC to python helps unify the GEMS and M5 configuration. As we all know this is a pretty significant challenge that will be solved in multiple steps. I just want to make sure we are all on the same path. Some of the generator files generate code that takes configuration parameters. I know that at least StateMachine::printControllerC at least does. Upon looking at it more closely, maybe this is the only one that does. So, maybe this isn't a huge benefit, but having an easier to understand generator should help. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Python SLICC
Just an FYI, I'm currently making changes to both the parser and code generator. I should be able to push those today if you want to hold off on the conversion. Ok, no problem. Let me know if you need any help updating parser.py. Also, for those of you SLICC experts out there, I'm curious if either of the following matter anymore (i.e. can they be removed) 1) MIF code generation? I'm guessing that this is actually broken. 2) CHECK_INVALID_RESOURCE_STALLS. Is this ever defined to be true? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: slicc: better error messages when the python pa...
changeset 0e78ffeebffd in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=0e78ffeebffd description: slicc: better error messages when the python parser fails diffstat: 1 file changed, 11 insertions(+), 4 deletions(-) src/mem/slicc/parser/parser.py | 15 +++ diffs (39 lines): diff -r 606cf4e1ade6 -r 0e78ffeebffd src/mem/slicc/parser/parser.py --- a/src/mem/slicc/parser/parser.pyMon Aug 03 11:06:19 2009 -0700 +++ b/src/mem/slicc/parser/parser.pyTue Aug 04 09:37:27 2009 -0700 @@ -100,8 +100,15 @@ t_ASSIGN = r':=' t_DOT = r'\.' -class TokenError(Exception): pass -class ParseError(Exception): pass +class TokenError(Exception): +def __init__(self, msg, t): +super(TokenError, self).__init__(msg) +self.token = t + +class ParseError(Exception): +def __init__(self, msg, t): +super(ParseError, self).__init__(msg) +self.token = t def t_error(t): raise TokenError(Illegal character, t) @@ -157,7 +164,7 @@ p[0] = [ x for x in p[1] if x is not None ] def p_error(t): -raise ParseError(t) +raise ParseError(Syntax error, t) def p_empty(p): empty : @@ -544,7 +551,7 @@ try: results = yacc.parse(file(filename, 'r').read()) except (TokenError, ParseError), e: -raise type(e), tuple([filename] + [ i for i in e ]) +sys.exit(%s: %s:%d % (e, filename, e.token.lineno)) for result in results: result.add(hh, cc) ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Scons cleaning
Yes, especially with the limited error messages SLICC spits out at the moment. When they aren't deleted it's difficult to even narrow down how far SLICC makes it before it fails; If they are deleted you can at least get an idea of which file SLICC gets stuck on. Ok. I spent some time trying to figure out how to do this and it's actually not going too well. I won't give up though. In the interim, can you just delete the build/foo/mem/protocol directory? I just pushed a fix to the error messages. Are they now what you'd expect? Thanks, Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Protocol Directories
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 the ability to have two different M5 binaries, using different protocols, co-exist in the same M5 tree. A solution similar to the current ALPHA_SE and ALPHA_FS binaries would be great. This can be done right now by using a different build directory for each protocol. You're used to having a scons target of build/ALPHA_FS/..., you can however do something like build/protocol/build/ALPHA_FS and that will cause things to be built in a different directory. You can even specify a full path that is not a subdirectory of the m5 dir. I should note that there is a limitation in the current SCons system in that the directory that ALPHA_FS, etc lives in must be called build. (The new version our stuff will have this limitation removed.) I want to better understand the motivation to compile multiple protocols into the same M5 binary. In my opinion, the comes down to the tradeoff of compile complexity and time vs. binary flexibility and testing. From my perspective, there is a lot of work involved to change the Ruby/SLICC interface to support a protocol template parameter. Though I'm sure with enough effort, it could be done. I assume that each protocol could be selectively compiled into the m5 binary and there would be some way to identify what specific protocols a M5 binary supports. Is that correct? So I'm curious to understand why we want to treat protocols differently from the compile time options like the ISA and SE vs. FS? All of these features seem to involve a lot of specific code used only by that feature. To me that seems to best match making them all compile time features, but I probably don't understand all the issues involved. I actually want to get rid of ISA and SE/FS as compile time parameters. It's a long term goal, but I'd prefer not to do things that make it worse. Basically, the problem is that m5 currently rebuilds everything if any compile time parameter changes. Because of this, as we add more compile time parameters, less of the simulator will be properly tested. (I'm pretty sure that few people compile all combinations of ISA and emulation.) As protocols multiply, this will get worse. Another downside of having multiple binaries is that it's easier to accidentally have one that is out of date. This can be particularly troublesome when running hundreds of simulations. I'm nearly done with a big overhaul of our SCons code that at least will not recompile files that don't depend on ISA or emulation or protocol. (the #defines will have to be explicitly #included and options to the Source directive in scons determine which #defines are available). This will significantly improve compile time and will probably solve most of the problem. We could stop here, but once this is done, it might not be hugely difficult to compile in multiple protocols if we just wrap the code in a protocol dependent namespace. Similarly, this might be a short cut for getting rid of ISA and FS/SE. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: X86: Fix segment override prefixes on instructi...
qemu has a tests directory and in it, there seems to be a pretty substantial tester for opcodes at least half of those opcodes are listed. Yes, thank you. That's been very helpful in general. I think someone actually recommended it before, but I'd misinterpreted the description of what was in there. To whoever that was, sorry I didn't listen! So, have you started using them already? Either way, it seems like it would be a great test to have in the regression suite. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: X86: Fix segment override prefixes on instructi...
The changes I pushed already mostly fix condition codes on existing instructions, plus rotates by more than the width of the target, plus a few minor fixes to multiply related microops. Moving forward in the short term, division instructions aren't getting the answers they should, and the test has a form of shift that shift one register out while shifting another one in that I don't have implemented. After that, I'm going to need to figure out how I want the various forms of FP instructions to work, aka microcoded or not, if so broken down how, how the register management will work, etc. Then I'd need to go in and implement a bunch of instructions. After that, there are sections of the test I commented out because I either suspect or know they won't work currently, perhaps because I'm using SE mode. I'd like to look at those more carefully and turn on the ones that are useful. There will potentially be things in there that are broken, and also things that are just incomplete or missing entirely. I'd like to point out to people that use m5 that this sounds like a point where some assistance on x86 could really accelerate things. While there will be some hard problems to solve I'm sure, I believe that people could help out in fleshing out the instruction set without a huge learning curve. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] gzstream library
When you compile m5 as a static library, e.g. scons build/ALPHA_SE/libm5_prof.a it doesn't compile gzstream into the library, nor does it link against a separate gzstream library, making the m5 library unusable. How can I make it compile gzstream? There should be a libgzstream.a in build/gzstream/libgzstream.a. You'll have to specify that in your final link stage along with -lm5_foo The reason things are this way is because we build an intermediate library for gzstream. We could instead just link gzstream.cc directly into m5 (the binary, shared lib, and static lib) that would require some scons hacking right now, but will be a lot easier once I finish my other scons stuff. I can add it to my todo list if people would prefer this. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] using gdb with memtest-ruby
I really need to use a debugging tool like gdb, but it seems that it just work with m5.debug. scons run memtest-ruby with m5.fast, how can I make it use m5.debug? In your scons target, you must have the word fast in there somewhere. If you replace it with debug, it should work. If this doesn't make sense, you're gonig to need to give us more information. What are the exact command lines you're using to build and run m5, and what are the error messages (if any) you're getting. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] gzstream library
I think this is because of the ordering on the command line. If I recall correctly, when two libraries depend on each other, the providing library needs to be listed *after* the consuming library. So you should put gzstream after m5. This is because with static libs linked with -l, the linker only takes unresolved symbols that it knows about from the library. If you were to link in the library as an object, i.e. full path with .a like you're linking libmemory.a, then this doesn't happen. Nate On Fri, Aug 7, 2009 at 12:20 PM, Derek Howerderek.ho...@gmail.com wrote: Command: g++ -o bochs -I/u/d/r/drh5/mfacet/rocks -I/u/d/r/drh5/mfacet/rocks/bochs -I/u/d/r/drh5/mfacet/rocks/gem5/src/mem/ruby -DBX_WITH_RUBY=1 -DBX_241=1 -g -pg -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DBX_SHARE_PATH=\/usr/local/share/bochs\ logio.o main.o config.o load32bitOShack.o pc_system.o osdep.o plugin.o crc.o -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -Wl,--export-dynamic -L/u/d/r/drh5/mfacet/rocks/gem5/build/LIBRUBY_MOESI_CMP_directory/../gzstream -L/u/d/r/drh5/mfacet/rocks/gem5/build/LIBRUBY_MOESI_CMP_directory iodev/libiodev.a cpu/libcpu.a memory/libmemory.a gui/libgui.a disasm/libdisasm.a ../bx_ruby_interface/libinstrument.a fpu/libfpu.a -L/usr/lib64 -lSM -lICE -lX11 -lXpm -lSDL -lncurses -lgzstream -lm5_prof -lpthread -lreadline -ltermcap -lm Errors: /u/d/r/drh5/mfacet/rocks/gem5/build/LIBRUBY_MOESI_CMP_directory/libm5_prof.a(Tracer.po): In function `Tracer::stopTrace()': /afs/cs.wisc.edu/p/multifacet/users/drh5/gem5/build/LIBRUBY_MOESI_CMP_directory/mem/ruby/recorder/Tracer.cc:95: undefined reference to `gzstreambase::close()' /u/d/r/drh5/mfacet/rocks/gem5/build/LIBRUBY_MOESI_CMP_directory/libm5_prof.a(Tracer.po): In function `ogzstream::open(char const*, int)': /afs/cs.wisc.edu/p/multifacet/users/drh5/gem5/build/gzstream/gzstream.hh:111: undefined reference to `gzstreambase::open(char const*, int)' /u/d/r/drh5/mfacet/rocks/gem5/build/LIBRUBY_MOESI_CMP_directory/libm5_prof.a(Tracer.po): In function `Tracer::stopTrace()': ...etc, etc -Derek On Fri, Aug 7, 2009 at 2:10 PM, nathan binkertn...@binkert.org wrote: How can I make it compile gzstream? There should be a libgzstream.a in build/gzstream/libgzstream.a. You'll have to specify that in your final link stage along with -lm5_foo Yes, there should, but theres not. If you build the dynamic library libgzstream.a gets built, but when you build the static library this is the contents of build/gzstream: ale-01:rocks (64)% ls gem5/build/gzstream/ gzstream.cc@ gzstream.hh@ SConscript@ I also built the dynamic m5 library so that libgztream.a would be created, but linking against it doesn't fix the problem. what is the error message you get and what is your linker command line? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] gzstream library
Well that is handy to know. Seems to do the trick. Thanks, Nate So, now how can I get scons to build the gzstream library when you specify a static library target? Well, you can just specify gzstream as a target: build/gzstream/libgzstream.a I think that the longer term solution is to just link the files directly in and not use -l. I'll work that into the next generation scons stuff. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH] bug fix for data_msg_size in network/Network.cc
Unless anybody has any concerns, I will try and check in the changes to the repository in an hour. Tushar, I don't have a problem with your patch, but an hour is not giving people enough time to review your patch. If your code is in a mercurial queue, there should be no big rush and you should at least wait a day if you don't get an OK, longer if your changes can affect a lot of people. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] configuration graph
How difficult would it be to generate a visual graph of the simboject heirarchy from within a config script? It might look something like Simulation.graph() similar to Simulation.run(...). I'm thinking that might be a good sanity check if someone wanted to make sure their simulation was actually set up the way they thought it was, and also to make it easier to quickly communicate experimental setups to other people. Support for this exists, but I don't think it's been tried in a long time. Look for outputDot in src/python/m5/SimObject.py. Be interesting to know if it works at all. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: python: Make it possible to import the parts of...
changeset 312b22c30c16 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=312b22c30c16 description: python: Make it possible to import the parts of m5 that are pure python diffstat: 1 file changed, 10 insertions(+), 3 deletions(-) src/python/m5/__init__.py | 13 ++--- diffs (27 lines): diff -r e21e9ab5fad0 -r 312b22c30c16 src/python/m5/__init__.py --- a/src/python/m5/__init__.py Sun Aug 16 13:39:58 2009 -0700 +++ b/src/python/m5/__init__.py Sun Aug 16 13:39:59 2009 -0700 @@ -103,8 +103,11 @@ except ImportError: internal = None -import defines -build_env.update(defines.buildEnv) +try: +import defines +build_env.update(defines.buildEnv) +except ImportError: +defines = None if internal: defines.compileDate = internal.core.compileDate @@ -120,4 +123,8 @@ import SimObject import params -import objects + +try: +import objects +except ImportError: +objects = None ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: ply: update PLY to version 3.2
changeset e21e9ab5fad0 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=e21e9ab5fad0 description: ply: update PLY to version 3.2 diffstat: 164 files changed, 9123 insertions(+), 3820 deletions(-) ext/ply/ANNOUNCE | 19 ext/ply/CHANGES| 332 ++ ext/ply/COPYING| 504 --- ext/ply/README | 101 ext/ply/TODO | 16 ext/ply/doc/internal.html | 874 + ext/ply/doc/makedoc.py | 10 ext/ply/doc/ply.html | 1099 -- ext/ply/example/BASIC/basic.py |9 ext/ply/example/BASIC/basiclex.py | 16 ext/ply/example/BASIC/basiclog.py | 79 ext/ply/example/BASIC/basinterp.py | 125 ext/ply/example/BASIC/basparse.py | 26 ext/ply/example/GardenSnake/GardenSnake.py | 28 ext/ply/example/ansic/clex.py | 20 ext/ply/example/ansic/cparse.py| 10 ext/ply/example/calc/calc.py | 24 ext/ply/example/calcdebug/calc.py | 113 ext/ply/example/classcalc/calc.py | 21 ext/ply/example/closurecalc/calc.py| 130 ext/ply/example/hedit/hedit.py | 12 ext/ply/example/newclasscalc/calc.py | 23 ext/ply/example/optcalc/README |2 ext/ply/example/optcalc/calc.py| 20 ext/ply/example/unicalc/calc.py|9 ext/ply/example/yply/ylex.py | 12 ext/ply/example/yply/yparse.py | 14 ext/ply/ply/cpp.py | 898 + ext/ply/ply/ctokens.py | 133 ext/ply/ply/lex.py | 986 +++--- ext/ply/ply/yacc.py| 4422 +--- ext/ply/setup.py | 25 ext/ply/test/calclex.py| 10 ext/ply/test/cleanup.sh|2 ext/ply/test/lex_closure.py| 54 ext/ply/test/lex_doc1.exp |1 ext/ply/test/lex_doc1.py |8 ext/ply/test/lex_dup1.exp |2 ext/ply/test/lex_dup1.py |6 ext/ply/test/lex_dup2.exp |2 ext/ply/test/lex_dup2.py |6 ext/ply/test/lex_dup3.exp |2 ext/ply/test/lex_dup3.py |6 ext/ply/test/lex_empty.exp |1 ext/ply/test/lex_empty.py |6 ext/ply/test/lex_error1.exp|1 ext/ply/test/lex_error1.py |6 ext/ply/test/lex_error2.exp|1 ext/ply/test/lex_error2.py |6 ext/ply/test/lex_error3.exp|2 ext/ply/test/lex_error3.py |6 ext/ply/test/lex_error4.exp|2 ext/ply/test/lex_error4.py |6 ext/ply/test/lex_hedit.exp |3 ext/ply/test/lex_hedit.py | 12 ext/ply/test/lex_ignore.exp|7 ext/ply/test/lex_ignore.py |4 ext/ply/test/lex_ignore2.exp |1 ext/ply/test/lex_ignore2.py|6 ext/ply/test/lex_literal1.py | 25 ext/ply/test/lex_literal2.py | 25 ext/ply/test/lex_many_tokens.py| 27 ext/ply/test/lex_module.py | 10 ext/ply/test/lex_module_import.py | 42 ext/ply/test/lex_nowarn.py | 30 ext/ply/test/lex_object.py | 55 ext/ply/test/lex_opt_alias.py | 54 ext/ply/test/lex_optimize.py | 50 ext/ply/test/lex_optimize2.py | 50 ext/ply/test/lex_optimize3.py | 52 ext/ply/test/lex_re1.exp |7 ext/ply/test/lex_re1.py|6 ext/ply/test/lex_re2.exp |7 ext/ply/test/lex_re2.py|6 ext/ply/test/lex_re3.exp |8 ext/ply/test/lex_re3.py|6 ext/ply/test/lex_rule1.exp |2 ext/ply/test/lex_rule1.py |8 ext/ply/test/lex_rule2.py | 29 ext/ply/test/lex_rule3.py | 27 ext/ply/test/lex_state1.exp|7 ext/ply/test/lex_state1.py | 10 ext/ply/test/lex_state2.exp|8 ext/ply/test/lex_state2.py | 10 ext/ply/test/lex_state3.exp|8 ext/ply/test/lex_state3.py | 12 ext/ply/test/lex_state4.exp|7 ext/ply/test/lex_state4.py | 14 ext/ply/test/lex_state5.exp|7 ext/ply/test/lex_state5.py | 12 ext/ply/test/lex_state_noerror.exp |1 ext/ply/test/lex_state_noerror.py | 12
[m5-dev] changeset in m5: orderdict: Use DictMixin and add orderdict to m...
changeset ee7587e7c71d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=ee7587e7c71d
description:
orderdict: Use DictMixin and add orderdict to m5.util
diffstat:
3 files changed, 29 insertions(+), 34 deletions(-)
src/python/SConscript |1
src/python/m5/util/__init__.py |1
src/python/m5/util/orderdict.py | 61 +--
diffs (104 lines):
diff -r 312b22c30c16 -r ee7587e7c71d src/python/SConscript
--- a/src/python/SConscript Sun Aug 16 13:39:59 2009 -0700
+++ b/src/python/SConscript Sun Aug 16 13:40:00 2009 -0700
@@ -56,6 +56,7 @@
PySource('m5.util', 'm5/util/jobfile.py')
PySource('m5.util', 'm5/util/misc.py')
PySource('m5.util', 'm5/util/multidict.py')
+PySource('m5.util', 'm5/util/orderdict.py')
SwigSource('m5.internal', 'swig/core.i')
SwigSource('m5.internal', 'swig/debug.i')
diff -r 312b22c30c16 -r ee7587e7c71d src/python/m5/util/__init__.py
--- a/src/python/m5/util/__init__.pySun Aug 16 13:39:59 2009 -0700
+++ b/src/python/m5/util/__init__.pySun Aug 16 13:40:00 2009 -0700
@@ -29,6 +29,7 @@
from attrdict import attrdict, optiondict
from misc import *
from multidict import multidict
+from orderdict import orderdict
import jobfile
def print_list(items, indent=4):
diff -r 312b22c30c16 -r ee7587e7c71d src/python/m5/util/orderdict.py
--- a/src/python/m5/util/orderdict.py Sun Aug 16 13:39:59 2009 -0700
+++ b/src/python/m5/util/orderdict.py Sun Aug 16 13:40:00 2009 -0700
@@ -28,17 +28,20 @@
__all__ = [ 'orderdict' ]
-class orderdict(dict):
-def __init__(self, d = {}):
-self._keys = d.keys()
-super(orderdict, self).__init__(d)
+from UserDict import DictMixin
+
+class orderdict(dict, DictMixin):
+def __init__(self, *args, **kwargs):
+if len(args) 1:
+raise TypeError(expected at most one argument, got %d % \
+len(args))
+self._keys = []
+self.update(*args, **kwargs)
def __setitem__(self, key, item):
+if key not in self:
+self._keys.append(key)
super(orderdict, self).__setitem__(key, item)
-if not hasattr(self, '_keys'):
-self._keys = [key,]
-if key not in self._keys:
-self._keys.append(key)
def __delitem__(self, key):
super(orderdict, self).__delitem__(key)
@@ -48,33 +51,23 @@
super(orderdict, self).clear()
self._keys = []
-def items(self):
-for i in self._keys:
-yield i, self[i]
+def iterkeys(self):
+for key in self._keys:
+yield key
+
+def itervalues(self):
+for key in self._keys:
+yield self[key]
+
+def iteritems(self):
+for key in self._keys:
+yield key, self[key]
def keys(self):
-return self._keys
-
-def popitem(self):
-if len(self._keys) == 0:
-raise KeyError('dictionary is empty')
-else:
-key = self._keys[-1]
-val = self[key]
-del self[key]
-return key, val
-
-def setdefault(self, key, failobj = None):
-super(orderdict, self).setdefault(key, failobj)
-if key not in self._keys:
-self._keys.append(key)
-
-def update(self, d):
-for key in d.keys():
-if not self.has_key(key):
-self._keys.append(key)
-super(orderdict, self).update(d)
+return self._keys[:]
def values(self):
-for i in self._keys:
-yield self[i]
+return [ self[key] for key in self._keys ]
+
+def items(self):
+return [ (self[key],key) for key in self._keys ]
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: ply: add a base class called Grammar that encap...
changeset 1b5863aba48c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=1b5863aba48c
description:
ply: add a base class called Grammar that encapsulates a ply grammar
diffstat:
2 files changed, 120 insertions(+)
src/python/SConscript |1
src/python/m5/util/grammar.py | 119 +
diffs (134 lines):
diff -r ee7587e7c71d -r 1b5863aba48c src/python/SConscript
--- a/src/python/SConscript Sun Aug 16 13:40:00 2009 -0700
+++ b/src/python/SConscript Sun Aug 16 13:40:01 2009 -0700
@@ -53,6 +53,7 @@
PySource('m5', 'm5/trace.py')
PySource('m5.util', 'm5/util/__init__.py')
PySource('m5.util', 'm5/util/attrdict.py')
+PySource('m5.util', 'm5/util/grammar.py')
PySource('m5.util', 'm5/util/jobfile.py')
PySource('m5.util', 'm5/util/misc.py')
PySource('m5.util', 'm5/util/multidict.py')
diff -r ee7587e7c71d -r 1b5863aba48c src/python/m5/util/grammar.py
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/src/python/m5/util/grammar.py Sun Aug 16 13:40:01 2009 -0700
@@ -0,0 +1,119 @@
+# Copyright (c) 2006-2009 Nathan Binkert n...@binkert.org
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are
+# met: redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer;
+# redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in the
+# documentation and/or other materials provided with the distribution;
+# neither the name of the copyright holders nor the names of its
+# contributors may be used to endorse or promote products derived from
+# this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR 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.
+
+from ply import lex, yacc
+
+class TokenError(lex.LexError):
+def __init__(self, msg, t):
+super(TokenError, self).__init__(msg)
+self.token = t
+
+class ParseError(yacc.YaccError):
+def __init__(self, message, token=None):
+super(ParseError, self).__init__(message)
+self.token = token
+
+class Tokenizer(object):
+def __init__(self, lexer, data):
+if isinstance(data, basestring):
+indata = [ data ]
+elif isinstance(data, file):
+indata = data.xreadlines()
+else:
+indata = data
+
+def _input():
+for i,line in enumerate(indata):
+lexer.lineno = i + 1
+lexer.input(line)
+while True:
+tok = lexer.token()
+if not tok:
+break
+yield tok
+self.input = _input()
+
+def next(self):
+return self.input.next()
+
+def __iter__(self):
+return self
+
+def token(self):
+try:
+return self.next()
+except StopIteration:
+return None
+
+class Grammar(object):
+def __init__(self, output=None, debug=False):
+self.yacc_args = {}
+self.yacc_args['debug'] = debug
+
+if output:
+import os
+
+dir,tab = os.path.split(output)
+if not tab.endswith('.py'):
+raise AttributeError, 'The output file must end with .py'
+self.yacc_args['outputdir'] = dir
+self.yacc_args['tabmodule'] = tab[:-3]
+
+def t_error(self, t):
+raise lex.LexError(Illegal character %s @ %d:%d % \
+ (`t.value[0]`, t.lineno, t.lexpos), `t.value[0]`)
+
+def p_error(self, t):
+if t:
+msg = Syntax error at %d:%d\n%s % \
+ (t.lineno, t.lexpos + 1, t.value)
+else:
+msg = Syntax error at end of input
+raise ParseError(msg, t)
+
+def __getattr__(self, attr):
+if attr == 'parser':
+import ply.yacc
+parser = ply.yacc.yacc(module=self, **self.yacc_args)
+self.parser = parser
+return parser
+
+if attr == 'lexer':
+import ply.lex
+lexer = ply.lex.lex(module=self
[m5-dev] changeset in m5: code_formatter: Add a python class for writing ...
changeset 6c7d9e9b3c83 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6c7d9e9b3c83
description:
code_formatter: Add a python class for writing code generator templates
diffstat:
3 files changed, 313 insertions(+)
src/python/SConscript|1
src/python/m5/util/__init__.py |1
src/python/m5/util/code_formatter.py | 311 ++
diffs (truncated from 337 to 300 lines):
diff -r 1b5863aba48c -r 6c7d9e9b3c83 src/python/SConscript
--- a/src/python/SConscript Sun Aug 16 13:40:01 2009 -0700
+++ b/src/python/SConscript Sun Aug 16 13:40:03 2009 -0700
@@ -53,6 +53,7 @@
PySource('m5', 'm5/trace.py')
PySource('m5.util', 'm5/util/__init__.py')
PySource('m5.util', 'm5/util/attrdict.py')
+PySource('m5.util', 'm5/util/code_formatter.py')
PySource('m5.util', 'm5/util/grammar.py')
PySource('m5.util', 'm5/util/jobfile.py')
PySource('m5.util', 'm5/util/misc.py')
diff -r 1b5863aba48c -r 6c7d9e9b3c83 src/python/m5/util/__init__.py
--- a/src/python/m5/util/__init__.pySun Aug 16 13:40:01 2009 -0700
+++ b/src/python/m5/util/__init__.pySun Aug 16 13:40:03 2009 -0700
@@ -27,6 +27,7 @@
# Authors: Nathan Binkert
from attrdict import attrdict, optiondict
+from code_formatter import code_formatter
from misc import *
from multidict import multidict
from orderdict import orderdict
diff -r 1b5863aba48c -r 6c7d9e9b3c83 src/python/m5/util/code_formatter.py
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/src/python/m5/util/code_formatter.py Sun Aug 16 13:40:03 2009 -0700
@@ -0,0 +1,311 @@
+# Copyright (c) 2006-2009 Nathan Binkert n...@binkert.org
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are
+# met: redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer;
+# redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in the
+# documentation and/or other materials provided with the distribution;
+# neither the name of the copyright holders nor the names of its
+# contributors may be used to endorse or promote products derived from
+# this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR 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.
+
+import inspect
+import os
+import re
+import string
+
+class lookup(object):
+def __init__(self, formatter, frame, *args, **kwargs):
+self.frame = frame
+self.formatter = formatter
+self.dict = self.formatter._dict
+self.args = args
+self.kwargs = kwargs
+self.locals = {}
+
+def __setitem__(self, item, val):
+self.locals[item] = val
+
+def __getitem__(self, item):
+if item in self.locals:
+return self.locals[item]
+
+if item in self.kwargs:
+return self.kwargs[item]
+
+if item == '__file__':
+return self.frame.f_code.co_filename
+
+if item == '__line__':
+return self.frame.f_lineno
+
+if item in self.dict:
+return self.dict[item]
+
+if self.formatter.locals or self.formatter.globals:
+if self.formatter.locals and item in self.frame.f_locals:
+return self.frame.f_locals[item]
+
+if self.formatter.globals and item in self.frame.f_globals:
+return self.frame.f_globals[item]
+
+if item in __builtins__:
+return __builtins__[item]
+
+try:
+item = int(item)
+return self.args[item]
+except ValueError:
+pass
+raise IndexError, Could not find '%s' % item
+
+class code_formatter_meta(type):
+pattern = r
+(?:
+ %(delim)s(?Pescaped%(delim)s) | # escaped delimiter
+ ^(?Pindent[ ]*)%(delim)s(?Plone%(ident)s)$ | # lone identifier
+ %(delim)s(?Pident%(ident)s)| # identifier
+ %(delim)s%(lb)s(?Pb_ident%(ident)s)%(rb)s | # braced identifier
+ %(delim)s(?Ppos%(pos)s)| # positional parameter
+ %(delim)s%(lb)s(?Pb_pos%(pos)s
[m5-dev] [PATCH 0 of 2] python implementation of slicc
Ok, so I finished the python translation of slicc. With the first patch applied, you can go into src/mem/pyslicc and run ./pyslicc. The output files can be diffed against the C++ slicc with -wBur. There's basically only minimal differences. The second diff changes the generated code output to be more inline with style and generally a bit easier to read. It also brings the comments back. Neither diff actually replaces the current slicc with python slicc in the build. Basically, I'd like people to more or less say that they're cool with this and then I'll generate a new diff that replaces slicc with this python version of slicc. A few things to determine. Where should the python slicc package live? It can stay in src/mem/slicc, or we can put it in src/python/slicc, or src/python/m5/slicc, though I'm not sure there's any utility to including it in the m5 binary (we could do that if we wanted though.) I also created a pyslicc executable that imports and runs slicc. Where should that go? I'm thinking util/slicc since it's only for convenience. The eventual SCons code will just import slicc and call it directly. Let me know what you guys think. Hopefully you agree that it's a whole lot easier to read the slicc code. I generate both html and c++. I do not do the mif code. I can pretty if it is worth it. I thought mif was for Framemaker, but someone said that it was for a model checker. Which is correct? I think we should keep something that is for a model checker, but I'm not convinced after looking at it that this is it. Oh yeah, I more or less kept the AST and grammar the way it was, though I did fix some shift/reduce conflicts that the existing grammars have. I would like to talk about removing some of the unused stuff from slicc, like check_stop_slots. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] [PATCH 2 of 2] slicc: Change the code generation so that the generated code is easier to read
# HG changeset patch
# User Nathan Binkert n...@binkert.org
# Date 1250457436 25200
# Node ID df4b8439bf23f13e4f1793d0dd928bec40cae2c4
# Parent a5771f288585269e01b3a7dd3029e8fd5d551764
slicc: Change the code generation so that the generated code is easier to read
diff --git a/src/mem/pyslicc/slicc/ast/PeekStatementAST.py
b/src/mem/pyslicc/slicc/ast/PeekStatementAST.py
--- a/src/mem/pyslicc/slicc/ast/PeekStatementAST.py
+++ b/src/mem/pyslicc/slicc/ast/PeekStatementAST.py
@@ -59,9 +59,10 @@
qcode = self.queue_name.var.code
code('''
{
+// Declare message
const $mtid* in_msg_ptr;
in_msg_ptr = dynamic_castconst $mtid *(($qcode).${{self.method}}());
-assert(in_msg_ptr != NULL);
+assert(in_msg_ptr != NULL); // Check the cast result
''')
# The other statements
diff --git a/src/mem/pyslicc/slicc/generate/html.py
b/src/mem/pyslicc/slicc/generate/html.py
--- a/src/mem/pyslicc/slicc/generate/html.py
+++ b/src/mem/pyslicc/slicc/generate/html.py
@@ -29,9 +29,11 @@
def createSymbol(symbol, title):
code = code_formatter()
-code('''HTMLBODYBIG
-$title:
-${{formatShorthand(symbol.short)}} - ${{symbol.desc}}/BIG/BODY/HTML''')
+code('''
+HTMLBODYBIG
+$title: ${{formatShorthand(symbol.short)}} - ${{symbol.desc}}
+/BIG/BODY/HTML
+''')
return code
def formatShorthand(short):
diff --git a/src/mem/pyslicc/slicc/symbols/Func.py
b/src/mem/pyslicc/slicc/symbols/Func.py
--- a/src/mem/pyslicc/slicc/symbols/Func.py
+++ b/src/mem/pyslicc/slicc/symbols/Func.py
@@ -97,7 +97,8 @@
params = ', '.join(self.param_strings)
code('''
-$return_type ${klass}::${{self.c_ident}}($params)
+$return_type
+${klass}::${{self.c_ident}}($params)
{
${{self.body}}
}
diff --git a/src/mem/pyslicc/slicc/symbols/StateMachine.py
b/src/mem/pyslicc/slicc/symbols/StateMachine.py
--- a/src/mem/pyslicc/slicc/symbols/StateMachine.py
+++ b/src/mem/pyslicc/slicc/symbols/StateMachine.py
@@ -143,14 +143,14 @@
self.message_buffer_names = []
code('''
-/** \\file $ident.hh
+/** \\file $c_ident.hh
*
* Auto generated C++ code started by $__file__:$__line__
* Created by slicc definition of Module ${{self.short}}
*/
-#ifndef ${ident}_CONTROLLER_H
-#define ${ident}_CONTROLLER_H
+#ifndef __${ident}_CONTROLLER_HH__
+#define __${ident}_CONTROLLER_HH__
#include mem/ruby/common/Global.hh
#include mem/ruby/common/Consumer.hh
@@ -170,9 +170,14 @@
code('''
extern stringstream ${ident}_transitionComment;
-class $c_ident : public AbstractController {
+class $c_ident : public AbstractController
+{
+// the coherence checker needs to call isBlockExclusive() and isBlockShared()
+// making the Chip a friend class is an easy way to do this for now
+
#ifdef CHECK_COHERENCE
#endif /* CHECK_COHERENCE */
+
public:
$c_ident(const string name);
static int getNumControllers();
@@ -187,6 +192,7 @@
void wakeup();
void printStats(ostream out) const { s_profiler.dumpStats(out); }
void clearStats() { s_profiler.clearStats(); }
+
private:
''')
@@ -202,8 +208,15 @@
code('''
int m_number_of_TBEs;
-TransitionResult doTransition(${ident}_Event event, ${ident}_State state,
const Address addr); // in ${ident}_Transitions.cc
-TransitionResult doTransitionWorker(${ident}_Event event, ${ident}_State
state, ${ident}_State next_state, const Address addr); // in
${ident}_Transitions.cc
+TransitionResult doTransition(${ident}_Event event,
+ ${ident}_State state,
+ const Address addr);
+
+TransitionResult doTransitionWorker(${ident}_Event event,
+${ident}_State state,
+${ident}_State next_state,
+const Address addr);
+
string m_name;
int m_transitions_per_cycle;
int m_buffer_size;
@@ -214,6 +227,7 @@
MachineID m_machineID;
${ident}_Profiler s_profiler;
static int m_num_controllers;
+
// Internal functions
''')
@@ -233,7 +247,7 @@
# the controller internal variables
code('''
-// Object
+// Objects
''')
for var in self.objects:
th = var.get(template_hack, )
@@ -244,7 +258,7 @@
code.dedent()
code('};')
-code('#endif // ${ident}_CONTROLLER_H')
+code('#endif // __${ident}_CONTROLLER_H__')
code.write(path, '%s.hh' % c_ident)
def printControllerCC(self, path):
@@ -255,7 +269,7 @@
c_ident = %s_Controller % self.ident
code('''
-/** \\file $ident.cc
+/** \\file $c_ident.cc
*
* Auto generated C++ code started by $__file__:$__line__
* Created by slicc definition of Module ${{self.short}}
@@ -280,8 +294,10 @@
code('''
int $c_ident::m_num_controllers = 0;
+// for adding information to the protocol debug trace
stringstream ${ident}_transitionComment;
#define APPEND_TRANSITION_COMMENT(str) (${ident}_transitionComment str)
+
/** \\brief
Re: [m5-dev] problem with running memtest-ruby in gem5?
What is the configuration for LIBRUBY_MESI_CMP? As far as I know, this is not in the development tree. On Mon, Aug 17, 2009 at 3:30 PM, Somayeh Sardashtisoma...@cs.wisc.edu wrote: Hi, I have found that in new version of gem5, when we make a protocol it does not create ALPHA_SE directory. It instead creates a specific directory like LIBRUBY_MESI_CMP_directory. Then I tried to run it using this: scons build/LIBRUBY_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby but it fails with this error in simerr: Traceback (most recent call last): File string, line 1, in ? File /afs/cs.wisc.edu/p/multifacet/users/somayeh/new_rocks/gem5/src/python/m5/main.py, line 359, in main exec filecode in scope File tests/run.py, line 65, in ? execfile(joinpath(tests_root, 'configs', config + '.py')) File tests/configs/memtest-ruby.py, line 35, in ? cpus = [ MemTest() for i in xrange(nb_cores) ] NameError: name 'MemTest' is not defined How can I fix this problem? Is the command that I am using wrong? (scons build/LIBRUBY_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby) Thanks, Somayeh ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] problem with running memtest-ruby in gem5?
You're building in a nonstandard way and you haven't committed your code or shown it to me, so I'm not sure how to help. You're not using ALPHA_SE, but something else. What is that somethign else? What does it do? Nate On Mon, Aug 17, 2009 at 6:42 PM, Somayeh Sardashtisoma...@cs.wisc.edu wrote: Yes, it is not in the tree because I have not pushed it yet. However I have the same problem with even MI_example. nathan binkert wrote: What is the configuration for LIBRUBY_MESI_CMP? As far as I know, this is not in the development tree. On Mon, Aug 17, 2009 at 3:30 PM, Somayeh Sardashtisoma...@cs.wisc.edu wrote: Hi, I have found that in new version of gem5, when we make a protocol it does not create ALPHA_SE directory. It instead creates a specific directory like LIBRUBY_MESI_CMP_directory. Then I tried to run it using this: scons build/LIBRUBY_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby but it fails with this error in simerr: Traceback (most recent call last): File string, line 1, in ? File /afs/cs.wisc.edu/p/multifacet/users/somayeh/new_rocks/gem5/src/python/m5/main.py, line 359, in main exec filecode in scope File tests/run.py, line 65, in ? execfile(joinpath(tests_root, 'configs', config + '.py')) File tests/configs/memtest-ruby.py, line 35, in ? cpus = [ MemTest() for i in xrange(nb_cores) ] NameError: name 'MemTest' is not defined How can I fix this problem? Is the command that I am using wrong? (scons build/LIBRUBY_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby) Thanks, Somayeh ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] problem with running memtest-ruby in gem5?
I've never used the default= thing (though I do know in theory what it should do.) Does it work if you don't use the default= option? Nate On Mon, Aug 17, 2009 at 8:11 PM, soma...@cs.wisc.edu wrote: The point is that even when I compile like this: scons default=ALPHA_SE build/ALPHA_SE/libm5_fast.so USE_MYSQL=No Ruby=True PROTOCOL=MI_example CPU_MODELS=AtomicSimpleCPU and then run with: scons build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby I see this in simerr: Traceback (most recent call last): File string, line 1, in ? File /afs/cs.wisc.edu/p/multifacet/users/somayeh/new_rocks/gem5/src/python/m5/main.py, line 359, in main exec filecode in scope File tests/run.py, line 65, in ? execfile(joinpath(tests_root, 'configs', config + '.py')) File tests/configs/memtest-ruby.py, line 35, in ? cpus = [ MemTest() for i in xrange(nb_cores) ] NameError: name 'MemTest' is not defined Somayeh LIBRUBY_MESI_CMP_directory is just the directory that the Rocks makefile will put M5. It is m5 compiled as: scons default=ALPHA_SE build/LIBRUBY_MESI_CMP_directory/libm5_fast.so USE_MYSQL=No Ruby=True PROTOCOL=MESI_CMP_directory CPU_MODELS=AtomicSimpleCPU -Derek On Mon, Aug 17, 2009 at 8:50 PM, nathan binkertn...@binkert.org wrote: You're building in a nonstandard way and you haven't committed your code or shown it to me, so I'm not sure how to help. You're not using ALPHA_SE, but something else. What is that somethign else? What does it do? Nate On Mon, Aug 17, 2009 at 6:42 PM, Somayeh Sardashtisoma...@cs.wisc.edu wrote: Yes, it is not in the tree because I have not pushed it yet. However I have the same problem with even MI_example. nathan binkert wrote: What is the configuration for LIBRUBY_MESI_CMP? As far as I know, this is not in the development tree. On Mon, Aug 17, 2009 at 3:30 PM, Somayeh Sardashtisoma...@cs.wisc.edu wrote: Hi, I have found that in new version of gem5, when we make a protocol it does not create ALPHA_SE directory. It instead creates a specific directory like LIBRUBY_MESI_CMP_directory. Then I tried to run it using this: scons build/LIBRUBY_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby but it fails with this error in simerr: Traceback (most recent call last): File string, line 1, in ? File /afs/cs.wisc.edu/p/multifacet/users/somayeh/new_rocks/gem5/src/python/m5/main.py, line 359, in main exec filecode in scope File tests/run.py, line 65, in ? execfile(joinpath(tests_root, 'configs', config + '.py')) File tests/configs/memtest-ruby.py, line 35, in ? cpus = [ MemTest() for i in xrange(nb_cores) ] NameError: name 'MemTest' is not defined How can I fix this problem? Is the command that I am using wrong? (scons build/LIBRUBY_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby) Thanks, Somayeh ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: X86: Make the real time clock actually keep tra...
I have a couple of comments on this changeset. First, I think this
has the potential to affect alpha, so you should run regressions.
(MC146818 is used by alpha for the clock).
An alternative it to just increment the fields and add rollover code.
It would a bunch of lines of code, but really easy and obviously
correct. The only somewhat complicated code would be rolling over the
month, but of course, that's not very difficult. In some ways, I think
this would be preferred because the timezone code lead to hidden
differences on platforms of stuff like leap seconds. I think we want
to say that every day has 86400 seconds. Period. no surprises. 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 Reinhardtste...@gmail.com wrote:
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 clock_data in readData() or writeData()?
In fact, you could get rid of the union altogether as a member (but
keep the type) and just create a local instance on each call to
readData() or writeData() that's dynamically populated from the time_t
curTime. (OK, on closer inspection that's not quite so clean since
you do need to store the *_alrm fields separately. So it probably is
easier just to keep the member, but treat all the fields other than
*_alrm as temporaries.)
I think you're also missing the step of updating curTime if clock_data
is changed in writeData(), independent of whether curTime is a struct
tm or a time_t.
BTW, I wanted to congratulate you on all the recent x86 progress,,,
this is looking awesome. I take it you're fixing the RTC because
you're now getting far enough to notice that it's not advancing?
Steve
On Thu, Aug 20, 2009 at 9:20 AM, Gabe Blackgbl...@eecs.umich.edu wrote:
changeset ade9a088bb14 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=ade9a088bb14
description:
X86: Make the real time clock actually keep track of time.
diffstat:
2 files changed, 103 insertions(+), 19 deletions(-)
src/dev/mc146818.cc | 96
---
src/dev/mc146818.hh | 26 +
diffs (184 lines):
diff -r de112a8ac3d8 -r ade9a088bb14 src/dev/mc146818.cc
--- a/src/dev/mc146818.cc Thu Aug 20 00:42:14 2009 -0700
+++ b/src/dev/mc146818.cc Thu Aug 20 00:42:43 2009 -0700
@@ -43,28 +43,20 @@
using namespace std;
-MC146818::MC146818(EventManager *em, const string n, const struct tm time,
- bool bcd, Tick frequency)
- : EventManager(em), _name(n), event(this, frequency)
+static uint8_t
+bcdize(uint8_t val)
{
- memset(clock_data, 0, sizeof(clock_data));
- stat_regA = RTCA_32768HZ | RTCA_1024HZ;
- stat_regB = RTCB_PRDC_IE | RTCB_24HR;
- if (!bcd)
- stat_regB |= RTCB_BIN;
+ uint8_t result;
+ result = val % 10;
+ result += (val / 10) 4;
+ return result;
+}
+void
+MC146818::setTime(const struct tm time)
+{
+ curTime = time;
year = time.tm_year;
-
- if (bcd) {
- // The datasheet says that the year field can be either BCD or
- // years since 1900. Linux seems to be happy with years since
- // 1900.
- year = year % 100;
- int tens = year / 10;
- int ones = year % 10;
- year = (tens 4) + ones;
- }
-
// Unix is 0-11 for month, data seet says start at 1
mon = time.tm_mon + 1;
mday = time.tm_mday;
@@ -75,6 +67,30 @@
// Datasheet says 1 is sunday
wday = time.tm_wday + 1;
+ if (!(stat_regB RTCB_BIN)) {
+ // The datasheet says that the year field can be either BCD or
+ // years since 1900. Linux seems to be happy with years since
+ // 1900.
+ year = bcdize(year % 100);
+ mon = bcdize(mon);
+ mday = bcdize(mday);
+ hour = bcdize(hour);
+ min = bcdize(min);
+ sec = bcdize(sec);
+ }
+}
+
+MC146818::MC146818(EventManager *em, const string n, const struct tm time,
+ bool bcd, Tick frequency)
+ : EventManager(em), _name(n), event(this, frequency), tickEvent(this)
+{
+ memset(clock_data, 0, sizeof(clock_data));
+ stat_regA = RTCA_32768HZ | RTCA_1024HZ;
+ stat_regB = RTCB_PRDC_IE | RTCB_24HR;
+ if (!bcd)
+ stat_regB |= RTCB_BIN;
+
+ setTime(time);
DPRINTFN(Real-time clock set to %s, asctime(time));
}
@@ -141,6 +157,34 @@
}
}
+static time_t
+mkutctime(struct tm *time)
+{
+ time_t ret;
+ char *tz;
+
+ tz = getenv(TZ);
+ setenv(TZ, , 1);
+ tzset();
+
Re: [m5-dev] changeset in m5: X86: Make the real time clock actually keep tra...
If it's all UTC then there's no daylight savings issue. Plus given the rate at which we simulate, we'd have to have a very poorly chosen starting time date to simulate across a leap second (from http://en.wikipedia.org/wiki/Leap_second: Leap seconds occur only at the end of a UTC month, and have only ever been inserted at the end of June 30 or December 31.). So if our canonical fake wall-clock time is Jan 1 (which I think it is), we'd have to simulate 6 months to hit a leap second... Basically I don't see a problem with using the library functions. Ok, I'm just worried that there are hidden things lurking in those library functions. They're not simple. You may notice that python doesn't even implement any timezone stuff in its library and leaves it up to the user. That's because it's not simple and it changes. I agree that UTC should be relatively safe though. An idle CPU could allow us to actually simulate 6months time :) I also worry that tzset isn't the same across unix/macos/windows. The main reason I'm so worried is that this could be a (perhaps unlikely) source of simulator differences that would potentially be very difficult to hunt down. Anyway, I think I'm not going to waste any more time talking about it since the code would take less time to write than to extend this discussion. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Templating language
So, I've been thinking about my old code_formatter thing that I've added to M5 recently and been wondering if it'd be better to just use one of the standard templating languages. I don't know much about them. I'm talking about things like genshi, cheetah, mako, django templates, etc. Does anyone know much about the differences between these? Does anyone know and love one of these? Keep in mind that the primary thing we do is generate C++ code, so things that are strictly geared towards html aren't useful. (Genshi is kinda cool because it supports both.) Gabe and Steve, it's probably worth looking at this sort of thing with respect to the isa_parser. It seems that it would be nice if code literals could be executed as templates, no? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] seg fault in typeinfo for Printable()
Have you tried a newer version of gcc to see what the code looks like?
Nate
On Mon, Aug 24, 2009 at 10:06 PM, Gabe Blackgbl...@eecs.umich.edu wrote:
This appears to be a gcc bug. I will now explain why. If you don't care,
stop reading. If you do care and you see some place where I'm wrong,
please, please let me know.
The interesting part of the function in question disassembles to the
following:
0x00d85fc3 _ZN16SimpleTimingPort10recvTimingEP6Packet+155:
mov 0x55ab4e(%rip),%rax # 0x12e0b18 curTick
0x00d85fca _ZN16SimpleTimingPort10recvTimingEP6Packet+162:
mov %rax,%rdx
0x00d85fcd _ZN16SimpleTimingPort10recvTimingEP6Packet+165:
add -0x8(%rbp),%rdx
0x00d85fd1 _ZN16SimpleTimingPort10recvTimingEP6Packet+169:
mov -0x20(%rbp),%rsi
0x00d85fd5 _ZN16SimpleTimingPort10recvTimingEP6Packet+173:
mov -0x18(%rbp),%rdi
0x00d85fd9 _ZN16SimpleTimingPort10recvTimingEP6Packet+177:
callq 0xd85d68 _ZN16SimpleTimingPort15schedSendTimingEP6Packetl
0x00d85fde _ZN16SimpleTimingPort10recvTimingEP6Packet+182:
jmp 0xd85ffb _ZN16SimpleTimingPort10recvTimingEP6Packet+211
0x00d85fe0 _ZN16SimpleTimingPort10recvTimingEP6Packet+184:
cmpq $0x0,-0x20(%rbp)
0x00d85fe5 _ZN16SimpleTimingPort10recvTimingEP6Packet+189:
je 0xd85ffb _ZN16SimpleTimingPort10recvTimingEP6Packet+211
0x00d85fe7 _ZN16SimpleTimingPort10recvTimingEP6Packet+191:
mov -0x20(%rbp),%rax
0x00d85feb _ZN16SimpleTimingPort10recvTimingEP6Packet+195:
mov (%rax),%rax
0x00d85fee _ZN16SimpleTimingPort10recvTimingEP6Packet+198:
add $0x8,%rax
0x00d85ff2 _ZN16SimpleTimingPort10recvTimingEP6Packet+202:
mov (%rax),%rax
0x00d85ff5 _ZN16SimpleTimingPort10recvTimingEP6Packet+205:
mov -0x20(%rbp),%rdi
0x00d85ff9 _ZN16SimpleTimingPort10recvTimingEP6Packet+209:
callq *%rax
0x00d85ffb _ZN16SimpleTimingPort10recvTimingEP6Packet+211:
movl $0x1,-0x24(%rbp)
0x00d86002 _ZN16SimpleTimingPort10recvTimingEP6Packet+218:
mov -0x24(%rbp),%eax
0x00d86005 _ZN16SimpleTimingPort10recvTimingEP6Packet+221:
leaveq
0x00d86006 _ZN16SimpleTimingPort10recvTimingEP6Packet+222: retq
The part where it has a heart attack is at +209 where it tries to call
through the value in memory pointed to by %rax. If you look above that a
few instructions at +191, you'll see where it gets a value off of the
stack using %rbp, the frame pointer, and puts that into %rax. That value
is the pointer pkt.
(gdb) p pkt
$7 = (PacketPtr) 0x1bd6f40
(gdb) p/x *(uint64_t)($rbp - 0x20)
$10 = 0x1bd6f40
Because pkts are reference counting pointers, %rax actually points to a
structure that contains the pointer to the real packet. The instruction
at +202 removes that level of indirection. Next, the line at +198 adds 8
to %rax, making it point to the vtable corresponding to the Printable
base class. You can see that here after all the static members.
(gdb) p *pkt
$11 = {FastAlloc = {_vptr.FastAlloc = 0x1bd7060, static Max_Alloc_Size
= 512, static Log2_Alloc_Quantum = 3, static Alloc_Quantum = 8, static
Num_Buckets = 65, static Num_Structs_Per_New = optimized out, static
freeLists = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2912c50, 0x0,
0x1bcf358, 0x2b7e8f0, 0x1bd61a0,
0x1bd6f40, 0x0 repeats 52 times}}, Printable =
{_vptr.Printable = 0xdd7d70}, static PUBLIC_FLAGS = optimized out,
static PRIVATE_FLAGS = optimized out, static COPY_FLAGS = 15, static
SHARED = 1, static EXPRESS_SNOOP = 2, static SUPPLY_EXCLUSIVE = 4,
static MEM_INHIBIT = 8, static VALID_ADDR = 256,
static VALID_SIZE = 512, static VALID_SRC = 1024, static VALID_DST =
2048, static STATIC_DATA = 4096, static DYNAMIC_DATA = 8192, static
ARRAY_DATA = 16384, flags = {_flags = 3840}, cmd = {static commandInfo =
0x12e6080, cmd = MemCmd::MessageResp}, req = 0x2b7e8f0, data = 0x0, addr
= 11529215046068469760,
size = 4, src = 0, dest = 8, origCmd = {static commandInfo =
0x12e6080, cmd = MemCmd::MessageReq}, time = 231966339456, finishTime =
231966444000, firstWordTime = 231966445000, static Broadcast = -1,
senderState = 0x0}
To make sure it's pointed at the right thing,
(gdb) p/x *(uint64_t *)((uint8_t *)pkt + 8)
$13 = 0xdd7d70
Next, we can see that %rax is again dereferenced at +202. This is
extracting the pointer to the virtual destructor of Printable from its
vtable.
(gdb) x/gx *(uint64_t *)((uint8_t *)pkt + 8)
0xdd7d70 _ZTV9Printable+16: 0x004e1f74
(gdb) disassemble 0x004e1f74
Dump of assembler code for function ~Printable:
0x004e1f74 ~Printable+0: push %rbp
0x004e1f75 ~Printable+1: mov %rsp,%rbp
0x004e1f78 ~Printable+4: sub $0x10,%rsp
0x004e1f7c ~Printable+8: mov %rdi,-0x8(%rbp)
0x004e1f80 ~Printable+12: mov $0xdd7d70,%edx
0x004e1f85 ~Printable+17: mov -0x8(%rbp),%rax
Re: [m5-dev] So somebody actually -does- use this stuff :)
Good point... if we wanted to be completely safe we'd either have to require a prototype to be in scope or forbid using instruction operands directly as function call operands altogether. I feel like I can probably help with some useful ideas, but I don't have a good enough picture of what's going on. Anyone want to do a 30-60 minute phone call to sort this out? If Gabe did a little bit of prep so he could figure out some code to walk us through (and telling us to do some prep like compiling the simulator is fine too), I think we could hammer a few things out quickly. I'm not clear on exactly what's going on here, but it seems to me that proxy classes could solve some of the type problems. For example, with partial template specialization, you can basically put a simple no-op wrapper around most types but flag any use of a non-const reference as a compiler error. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] splitting up decoder.cc
I see no mention of specific individuals in my comment! A lot depends on whether you can hack out a few contiguous 30,000-line chunks or if you'd have to do a lot of interleaving a few lines at a time to get it to work. Even in the latter case, some emacs macro creativity could possibly go a long way. I don't object to giving it a shot myself, but it won't be soon. I think one automated thing that can be done immediately is to separate out the disassembly. That should cut the filesize quite a bit. The disassembly will need a prototype for the class, but you can either duplicate it in the dissassembled class (duplicating generated code is not bad IMHO), or you can make one header per instruction. You may even want to try one disassemble file per opcode. We can bunch them together down the road if we've created the problem of too many files. That said, gcc can compile multiple .cc files at once into a single .o, not sure if we can get scons to deal with that though. One big issue with generating multiple files is that SCons needs to know what those files are *before* they are generated. I actually run the SLICC parser twice because of this. I build an AST both times, but the first time I simply look at the AST to figure out which files will be generated. The second time, I actually cause the generation to happen. Seems that this method ought to work for the isa stuff as well. I assume that the parsing of the ISA files isn't that expensive. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Extra 'ioctl' command codes
I think this simple patch is fine. We could in the future implement an IOCTL type dispatch like we have for syscalls, but that's overkill right now I think. Nate I noticed this a few days ago. The names aren't wrong, but they are architecture specific and currently there is only one set of them defined. The 'right' way is to split up the ioctl() by ISA, however since all we do is ignore them, I'm not certain that that effort is required. Thanks, Ali On Fri, 28 Aug 2009 10:03:01 +0100, Timothy M Jones tjon...@inf.ed.ac.uk wrote: Hi everyone, My final post for today, I hope :-P One of my binaries needed an unimplemented ioctl command code (TCSETAW). This patch adds it. However, I have a question about these codes and their names. At least in the kernel I'm looking at (2.6.15), there isn't a TIOCGETA or a TIOCGETS which are used in sim/syscall_emul.hh . However, there is a TCGETA and TCGETS which I believe is what is meant. Are these names wrong and should I change them? (Presumably this would require changing all ISAs?) Cheers Tim ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Enhancement to 'brk' system call
Tim, First, let me say that all of your work is awesome. Thanks for doing all of this. It was certainly a pleasant surprise. In your brk patch, I think the zero function on physical memory is not the right thing to do. You want to use a memory port and call memsetBlob on that port. Similar to how you called writeBlob in your time() patch. Is there some reason to think that this wouldn't work? I'll admit that brk could be a special case, but if it's not, it's better to use the port interface. I haven't managed to read through all of your patches, but as the resident anal coder, I'd like to request a few style fixes. 1) Can you make sure that you wrap lines at 80 columns? 2) I know it's probably not in our style guide, but can you make it so namespaces don't increase the indent? I know there's a lot of code in the tree that is indented because of the namespace, but it's really just a waste to do that. 3) the function name in a function definition should start on a new line (even if the definition is within a class declaration). e.g. inline void foo() 4) if, while, for, etc. should have a space before the paren since they're not functions. I realize that you copied a lot of existing code that got some of this wrong, but it'd be nice not to add new problems to the codebase. I hope you don't feel this is too big a burden. Finally, one last thing. Can you create at least a hello world regression test? More would of course be appreciated, but at least one would be nice. Are you using mercurial queues? My guess is that you are, but if not, you should. This is all great! I'm out of town for a while, so I may not be able to respond to questions very promptly. Hopefully others can continue to chime in. Thanks, Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
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 doesn't give any detailed error message; I think you'd have to run interactively on one of the pool machines to get that. I was actually thinking about a related idea. Would people prefer it if instead of having the whole g++ command line printed out during compile, we just printed a short description like, compiling sim/main.cc and wrote the details to a file. I could also try to control error messages so they print out at the end. This stuff would hopefully avoid compiler errors scrolling off the screen when you're doing a make -j32 or something like that. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] config patch
I will read it today. There are some issues. Please be a bit more patient. On Sep 1, 2009, at 8:15, Polina Dudnik pdud...@gmail.com wrote: I will push this if nobody has any objections. On Mon, Aug 31, 2009 at 4:48 PM, Polina Dudnik pdud...@gmail.com wrote: Hi, I am attaching a small patch that enables the passing of the ruby config file as a parameter. So, multiple protocols can be tested without manually modifying the config_file name. Comments are welcome. Polina ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] hooks: add m5threads
changeset d1bfbc434cca in /z/repo/hooks details: http://repo.m5sim.org/hooks?cmd=changeset;node=d1bfbc434cca summary: add m5threads diffstat: 1 file changed, 1 insertion(+) notify.ini |1 + diffs (11 lines): diff -r 61e0b644a4a1 -r d1bfbc434cca notify.ini --- a/notify.iniWed Feb 04 19:37:18 2009 -0500 +++ b/notify.iniSat Sep 05 20:42:19 2009 -0400 @@ -4,6 +4,7 @@ /z/repo/alpha-system = m5-dev@m5sim.org /z/repo/m5 = m5-dev@m5sim.org /z/repo/m5-stable = m5-dev@m5sim.org +/z/repo/m5threads = m5-dev@m5sim.org /z/repo/encumbered = m5-dev@m5sim.org /z/repo/hooks = m5-dev@m5sim.org /z/repo/inorder-patches = m5-dev@m5sim.org ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Syscall issue: exit() vs. exit_group()
The key issue is that SE mode does not support the Linux pthreads library... it's just too complicated (see http://m5sim.org/wiki/index.php/Splash_benchmarks). Daniel Sanchez at Stanford has written a lightweight pthreads library that uses a much reduced set of syscalls that SE mode does support; I don't recall off the top of my head if/where that is available though (Daniel?). It's actually hosted on m5sim.org. The threading support is in the simulator already and the library can be found at: http://repo.m5sim.org/m5threads/ ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] templating readMiscReg and setMiscReg
How often are these functions used? I'd have thought that they're not so frequent and wouldn't warrant optimization. Also, couldn't they just be inlined? Or is the variable obfuscated in such a way that the compiler doesn't know what it is at compile time? Nate Hello everybody. I was thinking the other day that it might be a good idea to templatize readMiscReg and setMiscReg. I don't have the idea fleshed out all the way, but I thought it would be a good idea to send an email to before I forgot about it. When we access control registers, my impression is that we almost always know which one we want. There are some exceptions where things are accessed in a loop, but usually there's a specific place where we need a specific register for a specific purpose. What happens, though, is that we call a function that handles -all- registers, and it has to switch on a parameter to redetermine what we wanted to do. If we called a specific function for, say, reading CR0, we'd skip the overhead of the switch statement. We'd also make the functions that set/read those registers shorter and more managable. In x86, I use bitunion types to split out the bitfields of a register. Because of that, basically each of the control registers already has a type that corresponds to it specifically. There are some exceptions where the same type is used for more than one register, but I don't think that's the common case. That type could be used as the template parameter to the read/set functions which would cause template instantiations all the way back into the isa object. Once there, template specialization would let you define a function that reads/sets just CR0, and the type system and C++ would plop it into place at the right place and time while still respecting interfaces. It might even be inlinable. The regular version that takes an index would still be available. I'm not quite sure how to fold it into the templated version of that function since the index is explicit, but since it's likely going to be (and probably should normally be) a MiscReg, that might work out. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: MI data corruption bug fix
I'm guessing that this changes the regression results. Did you re-run them?
Nate
On Fri, Sep 11, 2009 at 8:58 AM, pdud...@gmail.com wrote:
changeset deb20a55147c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=deb20a55147c
description:
MI data corruption bug fix
diffstat:
1 file changed, 32 insertions(+), 17 deletions(-)
src/mem/protocol/MI_example-dir.sm | 49 +++-
diffs (137 lines):
diff -r 5437a0eeb822 -r deb20a55147c src/mem/protocol/MI_example-dir.sm
--- a/src/mem/protocol/MI_example-dir.sm Fri Sep 11 10:59:08 2009 -0500
+++ b/src/mem/protocol/MI_example-dir.sm Fri Sep 11 10:59:35 2009 -0500
@@ -21,7 +21,8 @@
M_DRD, desc=Blocked on an invalidation for a DMA read;
M_DWR, desc=Blocked on an invalidation for a DMA write;
- M_DWRI, desc=Intermediate state M_DWR--I;
+ M_DWRI, desc=Intermediate state M_DWR--I;
+ M_DRDI, desc=Intermediate state M_DRD--I;
IM, desc=Intermediate state I--M;
MI, desc=Intermediate state M--I;
@@ -306,11 +307,11 @@
action(inv_sendCacheInvalidate, inv, desc=Invalidate a cache block) {
peek(dmaRequestQueue_in, DMARequestMsg) {
enqueue(forwardNetwork_out, RequestMsg, latency=directory_latency) {
- out_msg.Address := address;
- out_msg.Type := CoherenceRequestType:INV;
- out_msg.Requestor := machineID;
- out_msg.Destination := directory[in_msg.PhysicalAddress].Owner;
- out_msg.MessageSize := MessageSizeType:Writeback_Control;
+ out_msg.Address := address;
+ out_msg.Type := CoherenceRequestType:INV;
+ out_msg.Requestor := machineID;
+ out_msg.Destination := directory[in_msg.PhysicalAddress].Owner;
+ out_msg.MessageSize := MessageSizeType:Writeback_Control;
}
}
}
@@ -323,16 +324,15 @@
dmaRequestQueue_in.dequeue();
}
- action(l_writeDataToMemory, l, desc=Write PUTX data to memory) {
+ action(l_writeDataToMemory, pl, desc=Write PUTX data to memory) {
peek(requestQueue_in, RequestMsg) {
// assert(in_msg.Dirty);
// assert(in_msg.MessageSize == MessageSizeType:Writeback_Data);
directory[in_msg.Address].DataBlk := in_msg.DataBlk;
- DEBUG_EXPR(in_msg.Address);
- DEBUG_EXPR(in_msg.DataBlk);
+ //directory[in_msg.Address].DataBlk.copyPartial(in_msg.DataBlk,
addressOffset(in_msg.Address), in_msg.Len);
}
}
-
+
action(dwt_writeDMADataFromTBE, dwt, desc=DMA Write data to memory from
TBE) {
directory[address].DataBlk.copyPartial(TBEs[address].DataBlk,
addressOffset(TBEs[address].PhysicalAddress), TBEs[address].Len);
}
@@ -416,7 +416,8 @@
out_msg.Address := address;
out_msg.Type := MemoryRequestType:MEMORY_WB;
out_msg.OriginalRequestorMachId := in_msg.Requestor;
- //out_msg.DataBlk := in_msg.DataBlk;
+ // get incoming data
+ // out_msg.DataBlk := in_msg.DataBlk;
out_msg.DataBlk.copyPartial(TBEs[address].DataBlk,
addressOffset(TBEs[address].PhysicalAddress), TBEs[address].Len);
out_msg.MessageSize := in_msg.MessageSize;
//out_msg.Prefetch := in_msg.Prefetch;
@@ -448,23 +449,26 @@
}
action(w_writeDataToMemoryFromTBE, \w, desc=Write date to directory
memory from TBE) {
- directory[address].DataBlk := TBEs[address].DataBlk;
+ //directory[address].DataBlk := TBEs[address].DataBlk;
+ directory[address].DataBlk.copyPartial(TBEs[address].DataBlk,
addressOffset(TBEs[address].PhysicalAddress), TBEs[address].Len);
+
}
// TRANSITIONS
- transition({M_DRD, M_DWR, M_DWRI}, GETX) {
+ transition({M_DRD, M_DWR, M_DWRI, M_DRDI}, GETX) {
z_recycleRequestQueue;
}
transition({IM, MI, ID, ID_W}, {GETX, GETS, PUTX, PUTX_NotOwner} ) {
z_recycleRequestQueue;
}
-
+
transition({IM, MI, ID, ID_W}, {DMA_READ, DMA_WRITE} ) {
y_recycleDMARequestQueue;
}
+
transition(I, GETX, IM) {
//d_sendData;
qf_queueMemoryFetchRequest;
@@ -507,18 +511,27 @@
}
transition(M, DMA_READ, M_DRD) {
+ v_allocateTBE;
inv_sendCacheInvalidate;
p_popIncomingDMARequestQueue;
}
- transition(M_DRD, PUTX, I) {
+ transition(M_DRD, PUTX, M_DRDI) {
+ l_writeDataToMemory;
drp_sendDMAData;
c_clearOwner;
- a_sendWriteBackAck;
- d_deallocateDirectory;
+ l_queueMemoryWBRequest;
i_popIncomingRequestQueue;
}
+ transition(M_DRDI, Memory_Ack, I) {
+ l_sendWriteBackAck;
+ w_deallocateTBE;
+ d_deallocateDirectory;
+ l_popMemQueue;
+ }
+
+
transition(M, DMA_WRITE, M_DWR) {
v_allocateTBE;
inv_sendCacheInvalidate;
@@ -526,6 +539,7 @@
}
transition(M_DWR, PUTX, M_DWRI) {
+ l_writeDataToMemory;
qw_queueMemoryWBRequest_partialTBE;
c_clearOwner;
i_popIncomingRequestQueue;
@@ -547,6 +561,7 @@
}
transition(M, PUTX, MI) {
+ l_writeDataToMemory;
c_clearOwner;
Re: [m5-dev] changeset in m5: MI data corruption bug fix
Those are still broken on zizzer, by the way. We should really fix those soon so we don't discover a big mess when we finally do. Anyone got some free time to work on this? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] config patch
I finally read this diff. My comments are inline. In the future,
please use hg email which is found in the patchbomb extension. It
makes it far easier to comment on diffs since I can just then reply to
the e-mail without having to jump through hoops to get it into my
mailer.
Nate
diff -r 369b61762d7b -r e5a3ba0bbe88 tests/configs/memtest-ruby.py
--- a/tests/configs/memtest-ruby.py Mon Aug 31 16:38:22 2009 -0500
+++ b/tests/configs/memtest-ruby.py Mon Aug 31 16:39:59 2009 -0500
@@ -29,13 +29,15 @@
import m5
from m5.objects import *
+#MAX CORES IS 8 with the fals sharing method
typo: false
+assert(nb_cores 0 and nb_cores = 8)
+assert(nb_cores == int(nb_cores))
+assert(config_file != 'none')
-#MAX CORES IS 8 with the fals sharing method
-nb_cores = 8
cpus = [ MemTest() for i in xrange(nb_cores) ]
import ruby_config
-ruby_memory = ruby_config.generate(MI_example-homogeneous.rb, nb_cores)
+ruby_memory = ruby_config.generate(config_file, nb_cores)
# system simulated
system = System(cpu = cpus, funcmem = PhysicalMemory(),
why did you move nb_cores to run.py? I think that's the wrong place
for that. run.py is supposed to only run the script, nothing more.
If you want some place to stick ruby stuff, create another file that
all ruby tests can import.
diff -r 369b61762d7b -r e5a3ba0bbe88 tests/quick/50.memtest/test.py
--- a/tests/quick/50.memtest/test.py Mon Aug 31 16:38:22 2009 -0500
+++ b/tests/quick/50.memtest/test.py Mon Aug 31 16:39:59 2009 -0500
@@ -25,6 +25,8 @@
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# Authors: Ron Dreslinski
+import m5
+from m5.objects import *
MemTest.max_loads=1e5
MemTest.progress_interval=1e4
Is this actually necessary?
diff -r 369b61762d7b -r e5a3ba0bbe88 tests/run.py
--- a/tests/run.pyMon Aug 31 16:38:22 2009 -0500
+++ b/tests/run.pyMon Aug 31 16:39:59 2009 -0500
@@ -38,6 +38,7 @@
# single path arg encodes everything we need to know about test
(category, name, isa, opsys, config) = sys.argv[1].split('/')[-5:]
+(build, protocol) = sys.argv[1].split('/')[:2]
There's a better way to do this below.
# find path to directory containing this file
tests_root = os.path.dirname(__file__)
@@ -62,7 +63,15 @@
# build configuration
sys.path.append(joinpath(tests_root, 'configs'))
-execfile(joinpath(tests_root, 'configs', config + '.py'))
+nb_cores = 8
+config_file = 'none'
+if (protocol == 'LIBRUBY_MI_example'):
+ config_file = 'MI_example-homogeneous.rb'
+elif (protocol == 'LIBRUBY_MOESI_CMP_directory'):
+config_file = 'TwoLevel_SplitL1UnifiedL2.rb'
+
+globals = {'nb_cores':nb_cores, 'config_file':config_file}
The added code above should go into some sort of Ruby file. Also the
protocol variable is just something that you guys did and isn't how
the protocol is really stored. The right way to do it is add
'PROTOCOL' to export_vars in src/mem/protocol/SConsopts (See
src/mem/ruby/SConsopts for an example of how this is done.) You can
then use m5.build_env['PROTOCOL'] to get the actual protocol name.
(just grep for build_env in the tree to see examples).
+execfile(joinpath(tests_root, 'configs', config + '.py'), globals, globals)
Given that you shouldn't be sticking nb_cores and config_file here, I
don't think you should change this line.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Large Memory support in Ruby
Attached is a patch I would like to check in that allows Ruby to support a very large memory address space and high core count. Currently ruby uses a flat array to store the memory state of the system. This works well when the simulated system is roughly 4 GB or less, but is not practical for 128 GB+ systems. The patch provides the Directory Memory a sparse memory data structure, which is essentially a hierarchical map. The patch also includes various bug fixes including configuration string parsing and debug fixes. Let me know what you think. If I don’t hear any complaints within a week, I’ll go ahead and check it in. My biggest complaint is that you do too many different things in this patch. When working in a large group, you really, *really* need to make changesets cover just one change. There are a lot of things going on in this changeset that just seem to be unrelated. Separation will take a little while, but really isn't so bad if you use mercurial queues. Also, if you use mq to begin with and make it a habit to create new patches when you're working, this becomes a non issue. I'd like to see the following: 1) Please separate out any 64-bit fixes into a separate changeset. 2) Separate out the sparse memory stuff into its own changeset. I'd also love it if you separated the Ruby part of sparse memory from the actual memory management so we can use it elsewhere. The basic sparse memory stuff could go in src/base. 3) separate out the MI_example changes into its own changeset. 4) Separate out the debugging changes Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] templating readMiscReg and setMiscReg
That reminds me. Why do we have a convention of read/set? Why not read/write or set/get? It seems a little asymmetric, but admittedly probably not important enough to change in any case. I have no idea, but if you want to change it, I'd suggest read/write. Maybe at some point write meant something else. I don't even recall who did it in the first place. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] SPARC_SE hook up a few more syscalls
Did anyone ever import this code? If not, anyone see any reason not to?
On Wed, Jul 29, 2009 at 2:50 PM, Vince Weaver vi...@csl.cornell.edu wrote:
Hello
I'm trying to run gcc from spec2k under SPARC_SE and ran into a few
unimplemented syscalls. Attached is a patch that enables getrlimit and
getrusage and sets setrlimit to be ignored.
The code is modeled on the Alpha code and seems to work. gcc.spec2k still
doesn't work though. On expr it makes it about 1/3 the way through and
then fails out due to an illegal memory access.
Vince
diff -r b35ef789e6f6 src/arch/sparc/linux/linux.hh
--- a/src/arch/sparc/linux/linux.hh Wed Jul 29 00:35:49 2009 -0700
+++ b/src/arch/sparc/linux/linux.hh Wed Jul 29 17:42:04 2009 -0400
@@ -77,6 +77,31 @@
static const int NUM_OPEN_FLAGS;
static const unsigned TGT_MAP_ANONYMOUS = 0x20;
+
+ //@{
+ /// For getrusage().
+ static const int TGT_RUSAGE_SELF = 0;
+ static const int TGT_RUSAGE_CHILDREN = -1;
+ static const int TGT_RUSAGE_BOTH = -2;
+ //@}
+
+ /// Resource enumeration for getrlimit().
+ enum rlimit_resources {
+ TGT_RLIMIT_CPU = 0,
+ TGT_RLIMIT_FSIZE = 1,
+ TGT_RLIMIT_DATA = 2,
+ TGT_RLIMIT_STACK = 3,
+ TGT_RLIMIT_CORE = 4,
+ TGT_RLIMIT_RSS = 5,
+ TGT_RLIMIT_NOFILE = 6,
+ TGT_RLIMIT_AS = 7,
+ TGT_RLIMIT_VMEM = 7,
+ TGT_RLIMIT_NPROC = 8,
+ TGT_RLIMIT_MEMLOCK = 9,
+ TGT_RLIMIT_LOCKS = 10
+ };
+
+
};
class Sparc32Linux : public SparcLinux
diff -r b35ef789e6f6 src/arch/sparc/linux/syscalls.cc
--- a/src/arch/sparc/linux/syscalls.cc Wed Jul 29 00:35:49 2009 -0700
+++ b/src/arch/sparc/linux/syscalls.cc Wed Jul 29 17:42:04 2009 -0400
@@ -31,6 +31,9 @@
#include arch/sparc/linux/process.hh
#include sim/syscall_emul.hh
+using namespace std;
+using namespace SparcISA;
+
class LiveProcess;
class ThreadContext;
@@ -205,7 +208,7 @@
/* 114 */ SyscallDesc(sendmsg, unimplementedFunc),
/* 115 */ SyscallDesc(getgroups32, unimplementedFunc), //32 bit
/* 116 */ SyscallDesc(gettimeofday, gettimeofdayFuncSparc32Linux),
//32 bit
- /* 117 */ SyscallDesc(getrusage, unimplementedFunc), //32 bit
+ /* 117 */ SyscallDesc(getrusage, getrusageFuncSparc32Linux), //32 bit
/* 118 */ SyscallDesc(getsockopt, unimplementedFunc),
/* 119 */ SyscallDesc(getcwd, getcwdFunc),
/* 120 */ SyscallDesc(readv, unimplementedFunc),
@@ -232,8 +235,8 @@
/* 141 */ SyscallDesc(getpeername, unimplementedFunc),
/* 142 */ SyscallDesc(futex, unimplementedFunc), //32 bit
/* 143 */ SyscallDesc(gettid, unimplementedFunc),
- /* 144 */ SyscallDesc(getrlimit, unimplementedFunc),
- /* 145 */ SyscallDesc(setrlimit, unimplementedFunc),
+ /* 144 */ SyscallDesc(getrlimit, getrlimitFuncSparc32Linux),
+ /* 145 */ SyscallDesc(setrlimit, ignoreFunc),
/* 146 */ SyscallDesc(pivot_root, unimplementedFunc),
/* 147 */ SyscallDesc(prctl, unimplementedFunc), //32 bit
/* 148 */ SyscallDesc(pciconfig_read, unimplementedFunc),
@@ -511,7 +514,7 @@
/* 114 */ SyscallDesc(sendmsg, unimplementedFunc),
/* 115 */ SyscallDesc(getgroups32, unimplementedFunc),
/* 116 */ SyscallDesc(gettimeofday, gettimeofdayFuncSparcLinux),
- /* 117 */ SyscallDesc(getrusage, unimplementedFunc),
+ /* 117 */ SyscallDesc(getrusage, getrusageFuncSparcLinux),
/* 118 */ SyscallDesc(getsockopt, unimplementedFunc),
/* 119 */ SyscallDesc(getcwd, unimplementedFunc),
/* 120 */ SyscallDesc(readv, unimplementedFunc),
@@ -538,7 +541,7 @@
/* 141 */ SyscallDesc(getpeername, unimplementedFunc),
/* 142 */ SyscallDesc(futex, unimplementedFunc),
/* 143 */ SyscallDesc(gettid, unimplementedFunc),
- /* 144 */ SyscallDesc(getrlimit, unimplementedFunc),
+ /* 144 */ SyscallDesc(getrlimit, getrlimitFuncSparcLinux),
/* 145 */ SyscallDesc(setrlimit, unimplementedFunc),
/* 146 */ SyscallDesc(pivot_root, unimplementedFunc),
/* 147 */ SyscallDesc(prctl, unimplementedFunc),
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH 02 of 18] ruby: CacheMemory tag lookup uses a hash instead of a loop
One of my personal pet peeves is having code in the tree that's
commented out. Is there any reason to do this with a revision control
system? Either the code is good and should be kept, or it should just
be deleted and live in the history.
Nate
On Mon, Sep 14, 2009 at 3:14 PM, Derek Hower d...@cs.wisc.edu wrote:
# HG changeset patch
# User Derek Hower d...@cs.wisc.edu
# Date 1251212987 18000
# Node ID c47323cc8f988feaf0718626f80a1b7a5bdca18f
# Parent 79d81f0b6217455b4f7586f53693f139285771a6
ruby: CacheMemory tag lookup uses a hash instead of a loop
diff --git a/src/mem/ruby/system/CacheMemory.hh
b/src/mem/ruby/system/CacheMemory.hh
--- a/src/mem/ruby/system/CacheMemory.hh
+++ b/src/mem/ruby/system/CacheMemory.hh
@@ -156,6 +156,7 @@
// The first index is the # of cache lines.
// The second index is the the amount associativity.
+ m5::hash_mapAddress, int m_tag_index;
VectorVectorAbstractCacheEntry* m_cache;
VectorVectorint m_locked;
@@ -286,6 +287,12 @@
{
assert(tag == line_address(tag));
// search the set for the tags
+ m5::hash_mapAddress, int::const_iterator it = m_tag_index.find(tag);
+ if (it != m_tag_index.end())
+ if (m_cache[cacheSet][it-second]-m_Permission !=
AccessPermission_NotPresent)
+ return it-second;
+ return -1; // Not found
+ /*
for (int i=0; i m_cache_assoc; i++) {
if ((m_cache[cacheSet][i] != NULL)
(m_cache[cacheSet][i]-m_Address == tag)
@@ -294,6 +301,7 @@
}
}
return -1; // Not found
+ */
}
// Given a cache index: returns the index of the tag in a set.
@@ -303,11 +311,19 @@
{
assert(tag == line_address(tag));
// search the set for the tags
+ m5::hash_mapAddress, int::const_iterator it = m_tag_index.find(tag);
+ if (it != m_tag_index.end())
+ return it-second;
+ return -1; // Not found
+ /*
+ assert(tag == line_address(tag));
+ // search the set for the tags
for (int i=0; i m_cache_assoc; i++) {
if (m_cache[cacheSet][i] != NULL m_cache[cacheSet][i]-m_Address ==
tag)
return i;
}
return -1; // Not found
+ */
}
// PUBLIC METHODS
@@ -418,6 +434,7 @@
m_cache[cacheSet][i]-m_Address = address;
m_cache[cacheSet][i]-m_Permission = AccessPermission_Invalid;
m_locked[cacheSet][i] = -1;
+ m_tag_index[address] = i;
m_replacementPolicy_ptr-touch(cacheSet, i,
g_eventQueue_ptr-getTime());
@@ -439,6 +456,7 @@
delete m_cache[cacheSet][location];
m_cache[cacheSet][location] = NULL;
m_locked[cacheSet][location] = -1;
+ m_tag_index.erase(address);
}
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH 01 of 18] ruby: added random seed option to config scripts
This code reminds me that we really need to start having a plan to merge ruby/m5 code more. There are many things in both code bases and this is yet another example. Perhaps we can try to target that we all put some effort into this after ISCA. Nate On Mon, Sep 14, 2009 at 3:14 PM, Derek Hower d...@cs.wisc.edu wrote: # HG changeset patch # User Derek Hower d...@cs.wisc.edu # Date 1250630649 18000 # Node ID 79d81f0b6217455b4f7586f53693f139285771a6 # Parent 64bf776c5e704cd92fd6a1e286014bc39e96c90f ruby: added random seed option to config scripts diff --git a/src/mem/ruby/config/MI_example-homogeneous.rb b/src/mem/ruby/config/MI_example-homogeneous.rb --- a/src/mem/ruby/config/MI_example-homogeneous.rb +++ b/src/mem/ruby/config/MI_example-homogeneous.rb @@ -34,6 +34,13 @@ elsif $*[i] == -m num_memories = $*[i+1].to_i i = i+1 + elsif $*[i] == -R + if $*[i+1] == rand + RubySystem.random_seed = rand + else + RubySystem.random_seed = $*[i+1].to_i + end + i = i+ 1 elsif $*[i] == -s memory_size_mb = $*[i+1].to_i i = i + 1 diff --git a/src/mem/ruby/config/TwoLevel_SplitL1UnifiedL2.rb b/src/mem/ruby/config/TwoLevel_SplitL1UnifiedL2.rb --- a/src/mem/ruby/config/TwoLevel_SplitL1UnifiedL2.rb +++ b/src/mem/ruby/config/TwoLevel_SplitL1UnifiedL2.rb @@ -40,6 +40,13 @@ elsif $*[i] == -p num_cores = $*[i+1].to_i i = i+1 + elsif $*[i] == -R + if $*[i+1] == rand + RubySystem.random_seed = rand + else + RubySystem.random_seed = $*[i+1].to_i + end + i = i+ 1 elsif $*[i] == -s memory_size_mb = $*[i+1].to_i i = i + 1 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH 03 of 18] Automated merge with ssh://h...@m5sim.org/m5
Are you not using mercurial queues? Generally, you don't get merge
changesets when you do. Either way, it's not a major problem, but you
can keep the history cleaner if you do.
Nate
On Mon, Sep 14, 2009 at 3:14 PM, Derek Hower d...@cs.wisc.edu wrote:
# HG changeset patch
# User Derek Hower d...@cs.wisc.edu
# Date 1251213023 18000
# Node ID 19e532a296e0975cf7918b4d7e9ef80f1d392cac
# Parent e0c1c6d876499dc536cfdf0cd37736051f1fb760
# Parent c47323cc8f988feaf0718626f80a1b7a5bdca18f
Automated merge with ssh://h...@m5sim.org/m5
diff --git a/src/mem/ruby/config/MI_example-homogeneous.rb
b/src/mem/ruby/config/MI_example-homogeneous.rb
--- a/src/mem/ruby/config/MI_example-homogeneous.rb
+++ b/src/mem/ruby/config/MI_example-homogeneous.rb
@@ -34,6 +34,13 @@
elsif $*[i] == -m
num_memories = $*[i+1].to_i
i = i+1
+ elsif $*[i] == -R
+ if $*[i+1] == rand
+ RubySystem.random_seed = rand
+ else
+ RubySystem.random_seed = $*[i+1].to_i
+ end
+ i = i+ 1
elsif $*[i] == -s
memory_size_mb = $*[i+1].to_i
i = i + 1
diff --git a/src/mem/ruby/config/TwoLevel_SplitL1UnifiedL2.rb
b/src/mem/ruby/config/TwoLevel_SplitL1UnifiedL2.rb
--- a/src/mem/ruby/config/TwoLevel_SplitL1UnifiedL2.rb
+++ b/src/mem/ruby/config/TwoLevel_SplitL1UnifiedL2.rb
@@ -40,6 +40,13 @@
elsif $*[i] == -p
num_cores = $*[i+1].to_i
i = i+1
+ elsif $*[i] == -R
+ if $*[i+1] == rand
+ RubySystem.random_seed = rand
+ else
+ RubySystem.random_seed = $*[i+1].to_i
+ end
+ i = i+ 1
elsif $*[i] == -s
memory_size_mb = $*[i+1].to_i
i = i + 1
diff --git a/src/mem/ruby/system/CacheMemory.hh
b/src/mem/ruby/system/CacheMemory.hh
--- a/src/mem/ruby/system/CacheMemory.hh
+++ b/src/mem/ruby/system/CacheMemory.hh
@@ -156,6 +156,7 @@
// The first index is the # of cache lines.
// The second index is the the amount associativity.
+ m5::hash_mapAddress, int m_tag_index;
VectorVectorAbstractCacheEntry* m_cache;
VectorVectorint m_locked;
@@ -286,6 +287,12 @@
{
assert(tag == line_address(tag));
// search the set for the tags
+ m5::hash_mapAddress, int::const_iterator it = m_tag_index.find(tag);
+ if (it != m_tag_index.end())
+ if (m_cache[cacheSet][it-second]-m_Permission !=
AccessPermission_NotPresent)
+ return it-second;
+ return -1; // Not found
+ /*
for (int i=0; i m_cache_assoc; i++) {
if ((m_cache[cacheSet][i] != NULL)
(m_cache[cacheSet][i]-m_Address == tag)
@@ -294,6 +301,7 @@
}
}
return -1; // Not found
+ */
}
// Given a cache index: returns the index of the tag in a set.
@@ -303,11 +311,19 @@
{
assert(tag == line_address(tag));
// search the set for the tags
+ m5::hash_mapAddress, int::const_iterator it = m_tag_index.find(tag);
+ if (it != m_tag_index.end())
+ return it-second;
+ return -1; // Not found
+ /*
+ assert(tag == line_address(tag));
+ // search the set for the tags
for (int i=0; i m_cache_assoc; i++) {
if (m_cache[cacheSet][i] != NULL m_cache[cacheSet][i]-m_Address ==
tag)
return i;
}
return -1; // Not found
+ */
}
// PUBLIC METHODS
@@ -418,6 +434,7 @@
m_cache[cacheSet][i]-m_Address = address;
m_cache[cacheSet][i]-m_Permission = AccessPermission_Invalid;
m_locked[cacheSet][i] = -1;
+ m_tag_index[address] = i;
m_replacementPolicy_ptr-touch(cacheSet, i,
g_eventQueue_ptr-getTime());
@@ -439,6 +456,7 @@
delete m_cache[cacheSet][location];
m_cache[cacheSet][location] = NULL;
m_locked[cacheSet][location] = -1;
+ m_tag_index.erase(address);
}
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH 04 of 18] [mq]: first_patch
You are right and that's probably more my mistake than Dereks. What happens is that mercurial crashes whenever it would detect a white-space issue. So, for me to make a patch or commit I hacked the style file, and these changes made it into the patch. Send me the error message and I'll fix it. I can also make style.py ignore ruby files until such time we decide to do something about it. I don't know about Derek, but that is exactly what happened to me, and that is mainly due to lack of experience with mercurial patch queue. Unfortunately I learned about that after I made this mistake. I am sure Derek also did the same thing. If you guys need help fixing things after the fact, I can help. It's really not that scary to go into the .hg/patches directory (saving a copy) and muck with things. Basically, you pop all of your patches, edit the series file, and move patch hunks between files if necessary. It can be a bit tedious, but it's a major benefit to those that are reading your changes. It also allows you to find and fix bugs. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH] fix x86 loop instruction
Gabe,
If you didn't know, you can just take his patches and stick them in
your queue and use the -u option to qref to add his name to the
patch so he gets credit when you push.
Also, when people use hg email, you can just take the patch as is
and stick it in your queue since it contains all of the proper
directives to mercurial to get the date and user and such correct.
Nate
On Mon, Sep 14, 2009 at 8:52 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
Thank you for your patches. I'm a little buried right now, but they
are important, I -will- get to them eventually, and they'll more than
likely end up in the tree. Thanks!
Gabe
Quoting Vince Weaver vi...@csl.cornell.edu:
Hello
the loop instructions on x86 are broken, they seem to be using a
16-bit immediate for the offset instead of the proper signed 8-bit one.
This very obviously breaks instructions trying to loop backward.
The patch below fixes things on my regression test, though I might have
something wrong (the uop routines are a bit hard to follow). Also the
other two LOOP variations probably need the fix too.
This allows the x86 version of my regression test run properly
( http://deater.net/weave/vmwprod/asm/ll/qemu_tests.html )
Vince
diff -r 3b2d7fdff6b1
src/arch/x86/isa/insts/general_purpose/control_transfer/loop.py
---
a/src/arch/x86/isa/insts/general_purpose/control_transfer/loop.py Fri
Sep 11
16:19:31 2009 -0500
+++
b/src/arch/x86/isa/insts/general_purpose/control_transfer/loop.py Mon
Sep 14
22:51:52 2009 -0400
@@ -56,8 +56,9 @@
microcode = '''
def macroop LOOP_I {
rdip t1
+ limm t2, imm, dataSize=8
subi rcx, rcx, 1, flags=(EZF,), dataSize=asz
- wripi t1, imm, flags=(nCEZF,)
+ wrip t1, t2, flags=(nCEZF,)
};
def macroop LOOPNE_I {
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: Syscalls: Implement sysinfo() syscall.
I'm glad to see this go in. Has someone stepped up to make sure that
all of Vince's patches get in the tree?
Nate
On Tue, Sep 15, 2009 at 10:37 PM, Vince Weaver vi...@csl.cornell.edu wrote:
changeset 30d92d2b66a1 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=30d92d2b66a1
description:
Syscalls: Implement sysinfo() syscall.
diffstat:
11 files changed, 133 insertions(+), 7 deletions(-)
src/arch/alpha/linux/linux.hh | 15 +++
src/arch/alpha/linux/process.cc | 2 +-
src/arch/arm/linux/linux.hh | 15 +++
src/arch/arm/linux/process.cc | 2 +-
src/arch/mips/linux/linux.hh | 16
src/arch/mips/linux/process.cc | 2 +-
src/arch/sparc/linux/linux.hh | 32
src/arch/sparc/linux/syscalls.cc | 4 ++--
src/arch/x86/linux/linux.hh | 31 +++
src/arch/x86/linux/syscalls.cc | 4 ++--
src/sim/syscall_emul.hh | 17 +
diffs (285 lines):
diff -r ae3263589c7c -r 30d92d2b66a1 src/arch/alpha/linux/linux.hh
--- a/src/arch/alpha/linux/linux.hh Tue Sep 15 05:48:20 2009 -0700
+++ b/src/arch/alpha/linux/linux.hh Tue Sep 15 22:36:47 2009 -0700
@@ -125,6 +125,21 @@
TGT_RLIMIT_MEMLOCK = 9,
TGT_RLIMIT_LOCKS = 10
};
+
+ typedef struct {
+ int64_t uptime; /* Seconds since boot */
+ uint64_t loads[3]; /* 1, 5, and 15 minute load averages */
+ uint64_t totalram; /* Total usable main memory size */
+ uint64_t freeram; /* Available memory size */
+ uint64_t sharedram; /* Amount of shared memory */
+ uint64_t bufferram; /* Memory used by buffers */
+ uint64_t totalswap; /* Total swap space size */
+ uint64_t freeswap; /* swap space still available */
+ uint16_t procs; /* Number of current processes */
+ uint64_t totalhigh; /* Total high memory size */
+ uint64_t freehigh; /* Available high memory size */
+ uint64_t mem_unit; /* Memory unit size in bytes */
+ } tgt_sysinfo;
};
#endif // __ALPHA_ALPHA_LINUX_LINUX_HH__
diff -r ae3263589c7c -r 30d92d2b66a1 src/arch/alpha/linux/process.cc
--- a/src/arch/alpha/linux/process.cc Tue Sep 15 05:48:20 2009 -0700
+++ b/src/arch/alpha/linux/process.cc Tue Sep 15 22:36:47 2009 -0700
@@ -440,7 +440,7 @@
/* 315 */ SyscallDesc(munlock, unimplementedFunc),
/* 316 */ SyscallDesc(mlockall, unimplementedFunc),
/* 317 */ SyscallDesc(munlockall, unimplementedFunc),
- /* 318 */ SyscallDesc(sysinfo, unimplementedFunc),
+ /* 318 */ SyscallDesc(sysinfo, sysinfoFuncAlphaLinux),
/* 319 */ SyscallDesc(_sysctl, unimplementedFunc),
/* 320 */ SyscallDesc(was sys_idle, unimplementedFunc),
/* 321 */ SyscallDesc(oldumount, unimplementedFunc),
diff -r ae3263589c7c -r 30d92d2b66a1 src/arch/arm/linux/linux.hh
--- a/src/arch/arm/linux/linux.hh Tue Sep 15 05:48:20 2009 -0700
+++ b/src/arch/arm/linux/linux.hh Tue Sep 15 22:36:47 2009 -0700
@@ -147,6 +147,21 @@
uint64_t st_ino;
} tgt_stat64;
+ typedef struct {
+ int32_t uptime; /* Seconds since boot */
+ uint32_t loads[3]; /* 1, 5, and 15 minute load averages */
+ uint32_t totalram; /* Total usable main memory size */
+ uint32_t freeram; /* Available memory size */
+ uint32_t sharedram; /* Amount of shared memory */
+ uint32_t bufferram; /* Memory used by buffers */
+ uint32_t totalswap; /* Total swap space size */
+ uint32_t freeswap; /* swap space still available */
+ uint16_t procs; /* Number of current processes */
+ uint32_t totalhigh; /* Total high memory size */
+ uint32_t freehigh; /* Available high memory size */
+ uint32_t mem_unit; /* Memory unit size in bytes */
+ } tgt_sysinfo;
+
};
diff -r ae3263589c7c -r 30d92d2b66a1 src/arch/arm/linux/process.cc
--- a/src/arch/arm/linux/process.cc Tue Sep 15 05:48:20 2009 -0700
+++ b/src/arch/arm/linux/process.cc Tue Sep 15 22:36:47 2009 -0700
@@ -179,7 +179,7 @@
/* 113 */ SyscallDesc(vm86, unimplementedFunc),
/* 114 */ SyscallDesc(wait4, unimplementedFunc),
/* 115 */ SyscallDesc(swapoff, unimplementedFunc),
- /* 116 */ SyscallDesc(sysinfo, unimplementedFunc),
+ /* 116 */ SyscallDesc(sysinfo, sysinfoFuncArmLinux),
/* 117 */ SyscallDesc(ipc, unimplementedFunc),
/* 118 */ SyscallDesc(fsync, unimplementedFunc),
/* 119 */ SyscallDesc(sigreturn, unimplementedFunc),
diff -r ae3263589c7c -r 30d92d2b66a1 src/arch/mips/linux/linux.hh
--- a/src/arch/mips/linux/linux.hh Tue Sep 15 05:48:20 2009 -0700
+++ b/src/arch/mips/linux/linux.hh Tue Sep 15 22:36:47 2009 -0700
@@ -126,6 +126,22 @@
/// assign themselves to process IDs reserved for
/// the root users.
static const int NUM_ROOT_PROCS = 2;
+
+ typedef
Re: [m5-dev] [PATCH] fix SPARC udivcc instruction
This looks pretty obviously correct to me. I'll add it to my patch
queue and make sure that it doesn't break anything.
Nate
On Mon, Sep 14, 2009 at 10:14 PM, Vince Weaver vi...@csl.cornell.edu wrote:
Hello
the SPARC udivcc instruction was attempting to read bits 63:32 of a
uint32_t, which didn't work very well.
The below patch changes the value to uint64_t which fixes my test case.
Vince
diff -r 3b2d7fdff6b1 src/arch/sparc/isa/decoder.isa
--- a/src/arch/sparc/isa/decoder.isa Fri Sep 11 16:19:31 2009 -0500
+++ b/src/arch/sparc/isa/decoder.isa Tue Sep 15 01:14:42 2009 -0400
@@ -226,7 +226,8 @@
if(Rs2_or_imm13.udw == 0) fault = new DivisionByZero;
else Rd = Rs1.udw / Rs2_or_imm13.udw;}});
0x1E: IntOpCcRes::udivcc({{
- uint32_t resTemp, val2 = Rs2_or_imm13.udw;
+ uint64_t resTemp;
+ uint32_t val2 = Rs2_or_imm13.udw;
int32_t overflow = 0;
if(val2 == 0) fault = new DivisionByZero;
else
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH] configs: add maxinsts option to SE example
This seems fine for me. I'd adjust the commit message though since this will apply to both SE and FS. Nate On Mon, Sep 14, 2009 at 11:29 PM, Korey Sewell ksew...@eecs.umich.edu wrote: # HG changeset patch # User Korey Sewell ksew...@umich.edu # Date 1252996179 14400 # Node ID dcff60745367eae1e3d16294a55ff0982188dd26 # Parent cd671122f09c15ba25e42fe0cc0f5a1d29a8a31c configs: add maxinsts option to SE example allow threads to run to a max_inst_any_thread which is more useful/quicker in a lot of cases then always having to figure out what tick to run your simulation to diff --git a/configs/common/Options.py b/configs/common/Options.py --- a/configs/common/Options.py +++ b/configs/common/Options.py @@ -38,6 +38,7 @@ # Run duration options parser.add_option(-m, --maxtick, type=int) parser.add_option(--maxtime, type=float) +parser.add_option(--maxinsts, type=int) parser.add_option(--prog_intvl, type=int) diff --git a/configs/common/Simulation.py b/configs/common/Simulation.py --- a/configs/common/Simulation.py +++ b/configs/common/Simulation.py @@ -95,6 +95,10 @@ for i in xrange(np): testsys.cpu[i].progress_interval = options.prog_intvl + if options.maxinsts: + for i in xrange(np): + testsys.cpu[i].max_insts_any_thread = options.maxinsts + if cpu_class: switch_cpus = [cpu_class(defer_registration=True, cpu_id=(np+i)) for i in xrange(np)] ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: inorder-smt: remove hardcoded values
If possible, put the person's name, not just e-mail in the commit
message. i.e. Soumyaroop Roy s...@cse.usf.edu
Thanks,
Nate
On Wed, Sep 16, 2009 at 6:48 AM, s...@cse.usf.edu wrote:
changeset 0f7957bb4450 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=0f7957bb4450
description:
inorder-smt: remove hardcoded values
allows for the 2T hello world example to work in inorder model
diffstat:
1 file changed, 3 insertions(+), 3 deletions(-)
src/cpu/inorder/thread_state.hh | 6 +++---
diffs (28 lines):
diff -r 0b72f4f7c814 -r 0f7957bb4450 src/cpu/inorder/thread_state.hh
--- a/src/cpu/inorder/thread_state.hh Wed Sep 16 09:46:26 2009 -0400
+++ b/src/cpu/inorder/thread_state.hh Wed Sep 16 09:47:38 2009 -0400
@@ -78,13 +78,13 @@
#if FULL_SYSTEM
InOrderThreadState(InOrderCPU *_cpu, ThreadID _thread_num)
- : ThreadState(reinterpret_castBaseCPU*(_cpu), 0/*_thread_num*/),
+ : ThreadState(reinterpret_castBaseCPU*(_cpu), _thread_num),
cpu(_cpu), inSyscall(0), trapPending(0)
{ }
#else
InOrderThreadState(InOrderCPU *_cpu, ThreadID _thread_num,
Process *_process)
- : ThreadState(reinterpret_castBaseCPU*(_cpu), 0/*_thread_num*/,
+ : ThreadState(reinterpret_castBaseCPU*(_cpu), _thread_num,
_process),
cpu(_cpu), inSyscall(0), trapPending(0)
{ }
@@ -105,7 +105,7 @@
/** Returns a pointer to the TC of this thread. */
ThreadContext *getTC() { return tc; }
- int readTid() { return 0; }
+ int readTid() { return threadId(); }
/** Pointer to the last graduated instruction in the thread */
//DynInstPtr lastGradInst;
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] SPARC_SE hook up a few more syscalls
Not as far as I know, and no. Looking at this code generally, it would be nice to move the common definitions into a generic base class rather than have 32 bit SPARC inherit from 64 bit SPARC, but that's outside the scope of this patch. In general, there is a lot of repetition in the syscall code. Anyone know of a tool that can find duplicate code in a tree? I'll add this to my queue. (I noticed that that previous patch was already committed). Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: Rename internal Request fields to start with '_'.
This has been in my inbox forever and I figured I should just do it.
I guess B is nice since that's the way things are now, the question
is, what do we want new code to look like? Maybe it should more be
that private/protected members should start with an underscore and
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 ste...@gmail.com wrote:
Fine with me... one thing to clarify though is whether in the long run:
A. all class members should start with underscore just in case we want
to give them accessors later
or
B. only class members with accessors should start with underscore, and
others don't
I prefer B, mostly because A would be a much more invasive change, and
would be harder to enforce, and is generally uglier IMO. However it
does get a little confusing in that you end up with classes like
Request where privateFlags is about the only member that doesn't start
with an underscore. Constructors that allow you to set the initial
value of a field that has no accessors get even stranger, since the
convention there is that it's the constructor parameter that has the
underscore. That may not happen much, but it's still a possibility.
A is a little nicer in that you don't have to rename a field when you
change your mind about whether you have accessor methods.
Anyway, whichever way we decide to go we should make it explicit when
you update the style guide.
Steve
On Sun, Aug 2, 2009 at 1:10 PM, nathan binkertn...@binkert.org wrote:
Very awesome. I was tempted to do this a number of times. I'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 Reinhardtsteve.reinha...@amd.com
wrote:
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 as the fields.
This is also a first step to switching the accessors over to
our new standard, e.g., getVaddr() - vaddr().
diffstat:
1 file changed, 58 insertions(+), 56 deletions(-)
src/mem/request.hh | 114
++--
diffs (292 lines):
diff -r e46754b929ca -r 50125d42559c src/mem/request.hh
--- a/src/mem/request.hh Fri Jul 31 10:40:42 2009 -0400
+++ b/src/mem/request.hh Sat Aug 01 22:50:10 2009 -0700
@@ -132,17 +132,17 @@
* The physical address of the request. Valid only if validPaddr
* is set.
*/
- Addr paddr;
+ Addr _paddr;
/**
* The size of the request. This field must be set when vaddr or
* paddr is written via setVirt() or setPhys(), so it is always
* valid as long as one of the address fields is valid.
*/
- int size;
+ int _size;
/** Flag structure for the request. */
- Flags flags;
+ Flags _flags;
/** Private flags for field validity checking. */
PrivateFlags privateFlags;
@@ -155,15 +155,15 @@
Tick _time;
/** The address space ID. */
- int asid;
+ int _asid;
/** The virtual address of the request. */
- Addr vaddr;
+ Addr _vaddr;
/**
* Extra data for the request, such as the return value of
* store conditional or the compare value for a CAS. */
- uint64_t extraData;
+ uint64_t _extraData;
/** The context ID (for statistics, typically). */
int _contextId;
@@ -171,10 +171,13 @@
int _threadId;
/** program counter of initiating access; for tracing/debugging */
- Addr pc;
+ Addr _pc;
public:
- /** Minimal constructor. No fields are initialized. */
+ /** Minimal constructor. No fields are initialized.
+ * (Note that _flags and privateFlags are cleared by Flags
+ * default constructor.)
+ */
Request()
{}
@@ -218,23 +221,23 @@
* allocated Request object.
*/
void
- setPhys(Addr _paddr, int _size, Flags _flags, Tick time)
+ setPhys(Addr paddr, int size, Flags flags, Tick time)
{
- assert(_size = 0);
- paddr = _paddr;
- size = _size;
+ assert(size = 0);
+ _paddr = paddr;
+ _size = size;
_time = time;
- flags.clear(~STICKY_FLAGS);
- flags.set(_flags);
+ _flags.clear(~STICKY_FLAGS);
+ _flags.set(flags);
privateFlags.clear(~STICKY_PRIVATE_FLAGS);
privateFlags.set(VALID_PADDR|VALID_SIZE);
}
void
- setPhys(Addr _paddr, int _size, Flags _flags)
+ setPhys(Addr paddr, int size, Flags flags)
{
- setPhys(_paddr, _size, _flags, curTick);
+ setPhys(paddr, size, flags, curTick);
}
/**
@@ -242,18 +245,17 @@
* allocated Request
Re: [m5-dev] changeset in m5: Rename internal Request fields to start with '_'.
Sounds good. I'll update it. Nate On Wed, Sep 16, 2009 at 8:01 AM, Steve Reinhardt ste...@gmail.com wrote: I think if we're going to say that some fields have underscores and some don't, we should stick with saying that it's only the ones that have accessors that get underscores. Trying to introduce another dimension like public/private strikes me as something that will just add to the confusion and reduce compliance. One way to look at this is that normal code will generally not have variables with underscores... if it has an underscore, you should be using the accessor, even if you're in a method where you could access the field directly. So seeing a reference to a variable that starts with an underscore is a sign that something special is going on... either it's an accessor or a constructor (which should be obvious) or for some reason you're explicitly bypassing the accessor. Steve On Wed, Sep 16, 2009 at 7:25 AM, nathan binkert n...@binkert.org wrote: This has been in my inbox forever and I figured I should just do it. I guess B is nice since that's the way things are now, the question is, what do we want new code to look like? Maybe it should more be that private/protected members should start with an underscore and 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 ste...@gmail.com wrote: Fine with me... one thing to clarify though is whether in the long run: A. all class members should start with underscore just in case we want to give them accessors later or B. only class members with accessors should start with underscore, and others don't I prefer B, mostly because A would be a much more invasive change, and would be harder to enforce, and is generally uglier IMO. However it does get a little confusing in that you end up with classes like Request where privateFlags is about the only member that doesn't start with an underscore. Constructors that allow you to set the initial value of a field that has no accessors get even stranger, since the convention there is that it's the constructor parameter that has the underscore. That may not happen much, but it's still a possibility. A is a little nicer in that you don't have to rename a field when you change your mind about whether you have accessor methods. Anyway, whichever way we decide to go we should make it explicit when you update the style guide. Steve On Sun, Aug 2, 2009 at 1:10 PM, nathan binkertn...@binkert.org wrote: Very awesome. I was tempted to do this a number of times. I'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 Reinhardtsteve.reinha...@amd.com wrote: 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 as the fields. This is also a first step to switching the accessors over to our new standard, e.g., getVaddr() - vaddr(). diffstat: 1 file changed, 58 insertions(+), 56 deletions(-) src/mem/request.hh | 114 ++-- diffs (292 lines): diff -r e46754b929ca -r 50125d42559c src/mem/request.hh --- a/src/mem/request.hh Fri Jul 31 10:40:42 2009 -0400 +++ b/src/mem/request.hh Sat Aug 01 22:50:10 2009 -0700 @@ -132,17 +132,17 @@ * The physical address of the request. Valid only if validPaddr * is set. */ - Addr paddr; + Addr _paddr; /** * The size of the request. This field must be set when vaddr or * paddr is written via setVirt() or setPhys(), so it is always * valid as long as one of the address fields is valid. */ - int size; + int _size; /** Flag structure for the request. */ - Flags flags; + Flags _flags; /** Private flags for field validity checking. */ PrivateFlags privateFlags; @@ -155,15 +155,15 @@ Tick _time; /** The address space ID. */ - int asid; + int _asid; /** The virtual address of the request. */ - Addr vaddr; + Addr _vaddr; /** * Extra data for the request, such as the return value of * store conditional or the compare value for a CAS. */ - uint64_t extraData; + uint64_t _extraData; /** The context ID (for statistics, typically). */ int _contextId; @@ -171,10 +171,13 @@ int _threadId; /** program counter of initiating access; for tracing/debugging */ - Addr pc; + Addr _pc; public: - /** Minimal constructor. No fields are initialized. */ + /** Minimal constructor. No fields are initialized. + * (Note that _flags and privateFlags
Re: [m5-dev] changeset in m5: Rename internal Request fields to start with '_'.
http://www.m5sim.org/wiki/index.php/Coding_Style#Naming On Wed, Sep 16, 2009 at 8:19 AM, nathan binkert n...@binkert.org wrote: Sounds good. I'll update it. Nate On Wed, Sep 16, 2009 at 8:01 AM, Steve Reinhardt ste...@gmail.com wrote: I think if we're going to say that some fields have underscores and some don't, we should stick with saying that it's only the ones that have accessors that get underscores. Trying to introduce another dimension like public/private strikes me as something that will just add to the confusion and reduce compliance. One way to look at this is that normal code will generally not have variables with underscores... if it has an underscore, you should be using the accessor, even if you're in a method where you could access the field directly. So seeing a reference to a variable that starts with an underscore is a sign that something special is going on... either it's an accessor or a constructor (which should be obvious) or for some reason you're explicitly bypassing the accessor. Steve On Wed, Sep 16, 2009 at 7:25 AM, nathan binkert n...@binkert.org wrote: This has been in my inbox forever and I figured I should just do it. I guess B is nice since that's the way things are now, the question is, what do we want new code to look like? Maybe it should more be that private/protected members should start with an underscore and 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 ste...@gmail.com wrote: Fine with me... one thing to clarify though is whether in the long run: A. all class members should start with underscore just in case we want to give them accessors later or B. only class members with accessors should start with underscore, and others don't I prefer B, mostly because A would be a much more invasive change, and would be harder to enforce, and is generally uglier IMO. However it does get a little confusing in that you end up with classes like Request where privateFlags is about the only member that doesn't start with an underscore. Constructors that allow you to set the initial value of a field that has no accessors get even stranger, since the convention there is that it's the constructor parameter that has the underscore. That may not happen much, but it's still a possibility. A is a little nicer in that you don't have to rename a field when you change your mind about whether you have accessor methods. Anyway, whichever way we decide to go we should make it explicit when you update the style guide. Steve On Sun, Aug 2, 2009 at 1:10 PM, nathan binkertn...@binkert.org wrote: Very awesome. I was tempted to do this a number of times. I'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 Reinhardtsteve.reinha...@amd.com wrote: 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 as the fields. This is also a first step to switching the accessors over to our new standard, e.g., getVaddr() - vaddr(). diffstat: 1 file changed, 58 insertions(+), 56 deletions(-) src/mem/request.hh | 114 ++-- diffs (292 lines): diff -r e46754b929ca -r 50125d42559c src/mem/request.hh --- a/src/mem/request.hh Fri Jul 31 10:40:42 2009 -0400 +++ b/src/mem/request.hh Sat Aug 01 22:50:10 2009 -0700 @@ -132,17 +132,17 @@ * The physical address of the request. Valid only if validPaddr * is set. */ - Addr paddr; + Addr _paddr; /** * The size of the request. This field must be set when vaddr or * paddr is written via setVirt() or setPhys(), so it is always * valid as long as one of the address fields is valid. */ - int size; + int _size; /** Flag structure for the request. */ - Flags flags; + Flags _flags; /** Private flags for field validity checking. */ PrivateFlags privateFlags; @@ -155,15 +155,15 @@ Tick _time; /** The address space ID. */ - int asid; + int _asid; /** The virtual address of the request. */ - Addr vaddr; + Addr _vaddr; /** * Extra data for the request, such as the return value of * store conditional or the compare value for a CAS. */ - uint64_t extraData; + uint64_t _extraData; /** The context ID (for statistics, typically). */ int _contextId; @@ -171,10 +171,13 @@ int _threadId; /** program counter of initiating access; for tracing/debugging */ - Addr pc; + Addr _pc; public: - /** Minimal constructor
Re: [m5-dev] [PATCH] fix x86 loop instruction
I don't think you actually need the explicit (int16_t) cast here. Not a big deal though of course. Nate On Wed, Sep 16, 2009 at 9:22 AM, Vince Weaver vi...@csl.cornell.edu wrote: OK, I think I've fixed this. The key is the line: code = int16_t simm8 = (int16_t)((int8_t)imm8); + code I had to change your patch to have the extra int8_t cast, or else it wasn't sign extending the result. Below is the updated patch, which works for my test. Note, scons doesn't seem to see changes to regop.isa, at least on my machine. I had to manually remove m5.opt to get it to rebuild. Vince diff -r cb4c4b793106 src/arch/x86/isa/microops/regop.isa --- a/src/arch/x86/isa/microops/regop.isa Tue Sep 15 17:04:59 2009 -0400 +++ b/src/arch/x86/isa/microops/regop.isa Wed Sep 16 12:19:36 2009 -0400 @@ -324,11 +324,12 @@ matcher.sub(src2_name, flag_code), matcher.sub(src2_name, cond_check), matcher.sub(src2_name, else_code)) + imm_name = %simm8 % match.group(prefix) self.buildCppClasses(name + i, Name, suffix + Imm, - matcher.sub(imm8, code), - matcher.sub(imm8, flag_code), - matcher.sub(imm8, cond_check), - matcher.sub(imm8, else_code)) + matcher.sub(imm_name, code), + matcher.sub(imm_name, flag_code), + matcher.sub(imm_name, cond_check), + matcher.sub(imm_name, else_code)) return # If there's something optional to do with flags, generate @@ -353,13 +354,16 @@ matcher = re.compile((?!\w)spsrc2(?!\w)) if matcher.search(allCode): code = int64_t spsrc2 = signedPick(SrcReg2, 1, dataSize); + code + matcher = re.compile((?!\w)simm8(?!\w)) + if matcher.search(allCode): + code = int16_t simm8 = (int16_t)((int8_t)imm8); + code base = X86ISA::RegOp # If imm8 shows up in the code, use the immediate templates, if # not, hopefully the register ones will be correct. templates = regTemplates - matcher = re.compile((?!\w)imm8(?!\w)) + matcher = re.compile((?!\w)s?imm8(?!\w)) if matcher.search(allCode): base += Imm templates = immTemplates ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: Rename internal Request fields to start with '_'.
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 (and is the policy for python, *bsd, linux, etc) Also, what is the policy of splitting DPRINTF statements over multiple lines? e.g., DPRINTF(XYZ, THIS IS A DEBUG STATEMENT..., arg1, arg2, arg3, arg4); to be split up into 2 lines because of the 78 character limit: DPRINTF(XYZ, THIS IS A DEBUG STATEMENT..., arg1, arg2, arg3, arg4); or DPRINTF(XYZ, THIS IS A DEBUG STATEMENT..., arg1, arg2, arg3, arg4); or anything else. We don't specify how to indent subsequent lines. There are really three options I think. Indent 4 more than the previous indent level. Indent 8 more. Or align with the next scope. Emacs does the last by default. The first seems obvious, but the second is probably the nicest when indenting for things like an 'if' statement. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] memtest-ruby regression
I ran all regressions from a clean tree and the memtest-ruby regression test fails. Can one of the ruby people update it? (I'd just like you guys to sanity check the results). Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Large Memory support in Ruby
- 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, and there are more to come. That being said, I have no problem using the -X option to separate these out to multiple changesets when I commit them. I understand completely that this is in hindsight. It would just make things clearer for everyone if you broke things up more. The term unrelated was probably not quite right. Some things were unrelated, but it's more than that. When you can make things independent, that's good. - Sure, I can modify SparseMemory to be more abstract and move it to m5/base, but I probably then need to change SparseMemory to use the base/hashmap.hh object directly and not use gems_common/Map.hh. Directly using STL was one of things that original authors of Ruby never liked and that is why you don't see much direct usage of STL in Ruby today. I agree we need to start more tightly integrating Ruby and M5, and this is a good example to do so. It may take a while before I can find time to do this, but I'll try to give this a shot as soon as I can. I used to avoid using the STL when I was developing ASIM because it wasn't super stable, complete, or always available, but given it's current state, there's no good reason to do that now. It is my firm belief that everything in gems_common should be deprecated and removed with the exception of the stuff in util which is largely duplicates of stuff in base/intmath, but not completely. We'll also have to figure out the overlap between src/base refcounting stuff and the src/mem/gems_common stuff Does anyone have any strong objection to this attitude? 5. If the cache size can only be specified at the KB granularity, then how do perform small size tests like the random tester? Actually, upon further investigation, while the ruby-language configuration code says the size is in KBs, I don't see any 1024 multiplication in the actual CacheMemory::init function. How about we clear up the confusion and declare the cache size in bytes? What we really need to do is switch to using the python configuration stuff :) Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Large Memory support in Ruby
- 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, and there are more to come. That being said, I have no problem using the -X option to separate these out to multiple changesets when I commit them. What I do when that happens is refresh my current patch, pop it, write a patch that fixes whatever the issue is, refresh it, and then push my first patch back on. Then everything stays seperated into minimal logical units which makes history diving a lot nicer. Another thing that you can do if lots of things wind up in the same patch is to manually pull the patch apart into multiple patches. It sounds like a pain, but it's really not that hard to do. Also, I don't think the -X option works when you're using mq because when you convert an applied patch to a changeset (using hg qdel -r), you're not actually doing a commit. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Large Memory support in Ruby
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 new patch files and import them with 'hg qimport -e'. I personally just qpop everything, edit the files and create new ones and then update the series file. qimport -e is handy too. It may be just me, but I have a hard time determining in real time when a modification requires a new patch. After the fact, when the code is cleaned up, I can see the separation. However, when I'm first trying something, it is not always clear whether a modification is something I want to keep and deserves a separate patch. Once I was done I used the -X option with qrefresh to separate my internal and public changes to two separate patches, but now realize I should have also split my public changes into multiple patches as well. I think it's a talent that you can develop with experience... I think both things are common. 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 where they belong. I think qpop everything and qpush the patches one-by-one, making sure that they apply cleanly and qrefresh them once they do. The key is to start with smaller patches, and when you do end up making a mess out of things, clean it up sooner, rather than later. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Large Memory support in Ruby
To clarify Nate's statement (since it confused me at first): 'hg qdel -r' (which appears to be aliased to the much more logically named 'hg qfinish' in recent versions) huh, didn't know about qfinish. When you've already got a big monolithic patch like Brad does and want to split it up, then you are stuck with the somewhat manual task of pulling it apart. Some of the patchutils programs like filterdiff and splitdiff can help with this. If you use emacs, diff-mode is very helpful too. It will help you keep the patch correct if you add and remove lines. For example, when reading a diff, if I notice that I accidentally deleted or changed a line that I shouldn't have, I will edit the patch. It's tricky at first, but once you get the hang of it, it's really not that bad. For example, if I just added a blank line that I shouldn't have, I can just delete the line and emacs will fix up the diff. If I accidentally changed the line, I'll change the '-' at the beginning of the original line to a ' ' and delete the added line. Generally emacs can keep things straight for you when you do this. I'm guessing that vi can do the same. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Large Memory support in Ruby
The record/crecord extension might be useful to handle some of this. crecord looks very cool. Have you used it? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Large Memory support in Ruby
Yes... 'hg qfold' makes it trivial to combine smaller patches into larger ones, so it's better to err on the small side. The one thing about qfold is that is very crudely just sticks the commit messages from the two patches together, so make sure you fix it. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] debug_ss
When I run the regression tests, I get a file called debug_ss in my directory that is rather large. I'm assuming that this is some sort of debugging stuff for Ruby. Can whoever added this please remove it ASAP! Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: multiattrdict: make multilevel nesting work pro...
changeset 9e27313312e6 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=9e27313312e6 description: multiattrdict: make multilevel nesting work properly diffstat: 1 file changed, 5 insertions(+), 1 deletion(-) src/python/m5/util/attrdict.py |6 +- diffs (25 lines): diff -r f24b06320444 -r 9e27313312e6 src/python/m5/util/attrdict.py --- a/src/python/m5/util/attrdict.pyTue Sep 22 15:24:16 2009 -0700 +++ b/src/python/m5/util/attrdict.pyTue Sep 22 15:24:16 2009 -0700 @@ -58,7 +58,7 @@ try: return super(multiattrdict, self).__getattr__(attr) except AttributeError: -d = optiondict() +d = multiattrdict() setattr(self, attr, d) return d @@ -86,8 +86,12 @@ print dir(x) print(x) +print +print multiattrdict x = multiattrdict() +x.x.x.x = 9 x.y.z = 9 print x print x.y print x.y.z +print x.z.z ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: python: Move more code into m5.util allow SCons...
changeset 4c84e771cca7 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=4c84e771cca7 description: python: Move more code into m5.util allow SCons to use that code. Get rid of misc.py and just stick misc things in __init__.py Move utility functions out of SCons files and into m5.util Move utility type stuff from m5/__init__.py to m5/util/__init__.py Remove buildEnv from m5 and allow access only from m5.defines Rename AddToPath to addToPath while we're moving it to m5.util Rename read_command to readCommand while we're moving it Rename compare_versions to compareVersions while we're moving it. diffstat: 66 files changed, 845 insertions(+), 896 deletions(-) SConstruct| 68 +- configs/common/Caches.py |1 configs/common/FSConfig.py|2 configs/common/Simulation.py | 31 +-- configs/example/fs.py | 35 ++- configs/example/memtest.py|5 configs/example/ruby_se.py| 21 +- configs/example/se.py | 20 +- configs/splash2/cluster.py| 17 + configs/splash2/run.py|8 src/SConscript| 48 +++- src/arch/mips/BISystem.py |5 src/arch/mips/MipsCPU.py |5 src/arch/mips/MipsSystem.py |6 src/arch/x86/X86TLB.py|9 src/cpu/BaseCPU.py| 58 +++-- src/cpu/CheckerCPU.py |1 src/cpu/inorder/InOrderCPU.py |1 src/cpu/memtest/MemTest.py|1 src/cpu/o3/O3CPU.py |8 src/cpu/o3/O3Checker.py |1 src/cpu/ozone/OzoneCPU.py |6 src/cpu/ozone/OzoneChecker.py |1 src/cpu/ozone/SimpleOzoneCPU.py |4 src/cpu/simple/AtomicSimpleCPU.py |1 src/cpu/simple/TimingSimpleCPU.py |1 src/dev/Uart.py |1 src/mem/Bus.py|4 src/python/SConscript |5 src/python/m5/SimObject.py| 79 --- src/python/m5/__init__.py | 102 +- src/python/m5/convert.py | 250 - src/python/m5/environment.py | 43 src/python/m5/main.py |2 src/python/m5/params.py | 33 ++- src/python/m5/simulate.py |3 src/python/m5/smartdict.py| 154 --- src/python/m5/ticks.py|2 src/python/m5/trace.py|2 src/python/m5/util/__init__.py| 149 ++ src/python/m5/util/convert.py | 250 + src/python/m5/util/jobfile.py | 10 - src/python/m5/util/misc.py| 87 src/python/m5/util/smartdict.py | 154 +++ src/sim/System.py |5 tests/configs/inorder-timing.py |2 tests/configs/o3-timing-mp-ruby.py|2 tests/configs/o3-timing-mp.py |2 tests/configs/o3-timing-ruby.py |2 tests/configs/o3-timing.py|2 tests/configs/t1000-simple-atomic.py |2 tests/configs/tsunami-o3-dual.py |2 tests/configs/tsunami-o3.py |2 tests/configs/tsunami-simple-atomic-dual.py |2 tests/configs/tsunami-simple-atomic.py|2 tests/configs/tsunami-simple-timing-dual.py |2 tests/configs/tsunami-simple-timing.py|2 tests/configs/twosys-tsunami-simple-atomic.py |2 tests/long/00.gzip/test.py|2 tests/long/10.mcf/test.py |2 tests/long/20.parser/test.py |2 tests/long/30.eon/test.py |2 tests/long/40.perlbmk/test.py |2 tests/long/50.vortex/test.py |2 tests/long/60.bzip2/test.py |2 tests/long/70.twolf/test.py |2 diffs (truncated from 2876 to 300 lines): diff -r 9e27313312e6 -r 4c84e771cca7 SConstruct --- a/SConstructTue Sep 22 15:24:16 2009 -0700 +++ b/SConstructTue Sep 22 15:24:16 2009 -0700 @@ -96,6 +96,7 @@ raise +# Global Python includes import os import re import subprocess @@ -106,55 +107,14 @@ from os.path import exists, isdir, isfile from os.path import join as joinpath, split as splitpath +# SCons includes import SCons import SCons.Node -def read_command(cmd, **kwargs): -run the
[m5-dev] changeset in m5: scons: add slicc and ply to sys.path and PYTHON...
changeset 380a32b43336 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=380a32b43336
description:
scons: add slicc and ply to sys.path and PYTHONPATH so everyone has
access
diffstat:
4 files changed, 12 insertions(+), 17 deletions(-)
SConstruct | 19 ---
src/arch/isa_parser.py |5 -
src/arch/micro_asm.py |4
src/mem/protocol/SConscript |1 -
diffs (97 lines):
diff -r 4c84e771cca7 -r 380a32b43336 SConstruct
--- a/SConstructTue Sep 22 15:24:16 2009 -0700
+++ b/SConstructTue Sep 22 15:24:16 2009 -0700
@@ -111,8 +111,12 @@
import SCons
import SCons.Node
-# M5 includes
-sys.path[1:1] = [ Dir('src/python').srcnode().abspath ]
+extra_python_paths = [
+Dir('src/python').srcnode().abspath, # M5 includes
+Dir('ext/ply').srcnode().abspath, # ply is used by several files
+]
+
+sys.path[1:1] = extra_python_paths
from m5.util import compareVersions, readCommand
@@ -122,7 +126,7 @@
#
use_vars = set([ 'AS', 'AR', 'CC', 'CXX', 'HOME', 'LD_LIBRARY_PATH', 'PATH',
- 'RANLIB' ])
+ 'PYTHONPATH', 'RANLIB' ])
use_env = {}
for key,val in os.environ.iteritems():
@@ -133,6 +137,10 @@
main.root = Dir(.) # The current directory (where this file lives).
main.srcdir = Dir(src) # The source directory
+# add useful python code PYTHONPATH so it can be used by subprocesses
+# as well
+main.AppendENVPath('PYTHONPATH', extra_python_paths)
+
#
# Mercurial Stuff.
@@ -338,9 +346,6 @@
# the ext directory should be on the #includes path
main.Append(CPPPATH=[Dir('ext')])
-# M5_PLY is used by isa_parser.py to find the PLY package.
-main.Append(ENV = { 'M5_PLY' : Dir('ext/ply').abspath })
-
CXX_version = readCommand([main['CXX'],'--version'], exception=False)
CXX_V = readCommand([main['CXX'],'-V'], exception=False)
@@ -386,7 +391,7 @@
if sys.platform == 'cygwin':
# cygwin has some header file issues...
-main.Append(CCFLAGS=Split(-Wno-uninitialized))
+main.Append(CCFLAGS=-Wno-uninitialized)
# Check for SWIG
if not main.has_key('SWIG'):
diff -r 4c84e771cca7 -r 380a32b43336 src/arch/isa_parser.py
--- a/src/arch/isa_parser.pyTue Sep 22 15:24:16 2009 -0700
+++ b/src/arch/isa_parser.pyTue Sep 22 15:24:16 2009 -0700
@@ -34,11 +34,6 @@
# get type names
from types import *
-# Prepend the directory where the PLY lex yacc modules are found
-# to the search path. Assumes we're compiling in a subdirectory
-# of 'build' in the current tree.
-sys.path[0:0] = [os.environ['M5_PLY']]
-
from ply import lex
from ply import yacc
diff -r 4c84e771cca7 -r 380a32b43336 src/arch/micro_asm.py
--- a/src/arch/micro_asm.py Tue Sep 22 15:24:16 2009 -0700
+++ b/src/arch/micro_asm.py Tue Sep 22 15:24:16 2009 -0700
@@ -34,10 +34,6 @@
# get type names
from types import *
-# Prepend the directory where the PLY lex yacc modules are found
-# to the search path.
-sys.path[0:0] = [os.environ['M5_PLY']]
-
from ply import lex
from ply import yacc
diff -r 4c84e771cca7 -r 380a32b43336 src/mem/protocol/SConscript
--- a/src/mem/protocol/SConscript Tue Sep 22 15:24:16 2009 -0700
+++ b/src/mem/protocol/SConscript Tue Sep 22 15:24:16 2009 -0700
@@ -73,7 +73,6 @@
sources = [ protocol_dir.File(RubySlicc_interfaces.slicc),
protocol_dir.File(%s.slicc % protocol) ]
-sys.path[0:0] = [env['ENV']['M5_PLY']]
execfile(slicc_dir.File('parser/parser.py').srcnode().abspath)
sm_files = read_slicc([s.srcnode().abspath for s in sources])
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: params: small cleanup to param description inte...
changeset 69714e675ee2 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=69714e675ee2
description:
params: small cleanup to param description internals
diffstat:
2 files changed, 6 insertions(+), 7 deletions(-)
src/SConscript |7 +--
src/python/m5/params.py |6 +-
diffs (47 lines):
diff -r 380a32b43336 -r 69714e675ee2 src/SConscript
--- a/src/SConscriptTue Sep 22 15:24:16 2009 -0700
+++ b/src/SConscriptTue Sep 22 15:24:16 2009 -0700
@@ -489,12 +489,7 @@
# Generate any parameter header files needed
params_i_files = []
for name,param in all_params.iteritems():
-if isinstance(param, m5.params.VectorParamDesc):
-ext = 'vptype'
-else:
-ext = 'ptype'
-
-i_file = File('params/%s_%s.i' % (name, ext))
+i_file = File('params/%s_%s.i' % (name, param.file_ext))
params_i_files.append(i_file)
env.Command(i_file, Value(name), createSwigParam)
env.Depends(i_file, depends)
diff -r 380a32b43336 -r 69714e675ee2 src/python/m5/params.py
--- a/src/python/m5/params.py Tue Sep 22 15:24:16 2009 -0700
+++ b/src/python/m5/params.py Tue Sep 22 15:24:16 2009 -0700
@@ -93,6 +93,8 @@
# Regular parameter description.
class ParamDesc(object):
+file_ext = 'ptype'
+
def __init__(self, ptype_str, ptype, *args, **kwargs):
self.ptype_str = ptype_str
# remember ptype only if it is provided
@@ -127,7 +129,7 @@
def __getattr__(self, attr):
if attr == 'ptype':
ptype = SimObject.allClasses[self.ptype_str]
-assert issubclass(ptype, SimObject.SimObject)
+assert isSimObjectClass(ptype)
self.ptype = ptype
return ptype
@@ -182,6 +184,8 @@
v.print_ini(ini_file)
class VectorParamDesc(ParamDesc):
+file_ext = 'vptype'
+
# Convert assigned value to appropriate type. If the RHS is not a
# list or tuple, it generates a single-element list.
def convert(self, value):
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: slicc: Pure python implementation of slicc.
/slicc/symbols/Transition.hh | 120 -
src/mem/slicc/symbols/Transition.py | 61
src/mem/slicc/symbols/Type.cc | 779 --
src/mem/slicc/symbols/Type.hh | 155 --
src/mem/slicc/symbols/Type.py | 650
src/mem/slicc/symbols/Var.cc| 57
src/mem/slicc/symbols/Var.hh| 98 -
src/mem/slicc/symbols/Var.py| 50
src/mem/slicc/symbols/__init__.py | 38
src/mem/slicc/util.py | 75 +
util/slicc | 38
diffs (truncated from 22490 to 300 lines):
diff -r 69714e675ee2 -r ef5fae93a3b2 src/mem/protocol/SConscript
--- a/src/mem/protocol/SConscript Tue Sep 22 15:24:16 2009 -0700
+++ b/src/mem/protocol/SConscript Tue Sep 22 18:12:39 2009 -0700
@@ -29,30 +29,56 @@
# Authors: Nathan Binkert
import os
-import re
-import string
import sys
-from os.path import basename, dirname, exists, expanduser, isdir, isfile
-from os.path import join as joinpath
-
-import SCons
+from os.path import isdir, isfile, join as joinpath
Import('*')
if not env['RUBY']:
Return()
-slicc_dir = Dir('../slicc')
protocol_dir = Dir('.')
html_dir = Dir('html')
+slicc_dir = Dir('../slicc')
+
+sys.path[1:1] = [ Dir('..').srcnode().abspath ]
+from slicc.parser import SLICC
+
+slicc_depends = []
+for root,dirs,files in os.walk(slicc_dir.srcnode().abspath):
+for f in files:
+if f.endswith('.py'):
+slicc_depends.append(File(joinpath(root, f)))
#
# Use SLICC
#
-def slicc_generator(target, source, env, for_signature):
-slicc_bin = str(source[0])
-protocol = source[1].get_contents()
+
+def slicc_scanner(node, env, path):
+contents = node.get_contents()
+files = [ line.strip() for line in contents.splitlines() ]
+return files
+
+env.Append(SCANNERS=Scanner(function=slicc_scanner,skeys=['.slicc']))
+
+def slicc_emitter(target, source, env):
+files = [s.srcnode().abspath for s in source[1:]]
+slicc = SLICC(debug=True)
+print SLICC parsing...
+for name in slicc.load(files, verbose=True):
+print %s % name
+
+hh,cc = slicc.files()
+target.extend(sorted(hh))
+target.extend(sorted(cc))
+f = file('/tmp/asdf', 'w')
+for t in target:
+print f, t
+return target, source
+
+def slicc_action(target, source, env):
+protocol = source[0].get_contents()
pdir = str(protocol_dir)
hdir = str(html_dir)
@@ -61,31 +87,31 @@
if not isdir(hdir):
os.mkdir(hdir)
-do_html = html
-cmdline = [ slicc_bin, pdir, hdir, protocol, do_html ]
-cmdline += [ str(s) for s in source[2:] ]
-cmdline = ' '.join(cmdline)
-return cmdline
+slicc = SLICC(debug=True)
+files = [str(s) for s in source[1:]]
+slicc.load(files, verbose=False)
-slicc_builder = Builder(generator=slicc_generator)
+print SLICC Generator pass 1...
+slicc.findMachines()
+
+print SLICC Generator pass 2...
+slicc.generate()
+
+print SLICC writing C++ files...
+slicc.writeCodeFiles(pdir)
+
+print SLICC writing HTML files...
+slicc.writeHTMLFiles(hdir)
+
+slicc_builder = Builder(action=slicc_action, emitter=slicc_emitter)
protocol = env['PROTOCOL']
sources = [ protocol_dir.File(RubySlicc_interfaces.slicc),
protocol_dir.File(%s.slicc % protocol) ]
-execfile(slicc_dir.File('parser/parser.py').srcnode().abspath)
+env.Append(BUILDERS={'SLICC' : slicc_builder})
+nodes = env.SLICC([], [ Value(protocol) ] + sources)
+env.Depends(nodes, slicc_depends)
-sm_files = read_slicc([s.srcnode().abspath for s in sources])
-sm_files = [ protocol_dir.File(f) for f in sm_files ]
-
-hh, cc = scan([s.srcnode().abspath for s in sm_files])
-hh = [ protocol_dir.File(f) for f in hh ]
-cc = [ protocol_dir.File(f) for f in cc ]
-
-slicc_bin = slicc_dir.File(slicc)
-
-env.Append(BUILDERS={'SLICC' : slicc_builder})
-env.SLICC(hh + cc, [ slicc_bin, Value(protocol) ] + sm_files)
-
-for f in cc:
+for f in sorted(s for s in nodes if str(s).endswith('.cc')):
Source(f)
diff -r 69714e675ee2 -r ef5fae93a3b2 src/mem/slicc/SConscript
--- a/src/mem/slicc/SConscript Tue Sep 22 15:24:16 2009 -0700
+++ /dev/null Thu Jan 01 00:00:00 1970 +
@@ -1,129 +0,0 @@
-# -*- mode:python -*-
-
-# Copyright (c) 2009 The Hewlett-Packard Development Company
-# All rights reserved.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions are
-# met: redistributions of source code must retain the above copyright
-# notice, this list of conditions and the following disclaimer;
-# redistributions in binary form must reproduce the above copyright
-# notice, this list of conditions and the following disclaimer in the
-# documentation and/or other materials provided with the distribution;
-# neither the name of the copyright holders
Re: [m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression --scratch all
OK, it looks like changeset 6650 which fixed command line arguments (argc/argv) in MIPS switches up the initiliazation path of the code which in turn creates slightly different stats in instruction count and other things. I think it's OK to update the regression references. OK to update them all in one changeset (about 5 diff. regression stats) or should I split them? one is fine with me. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH 3/7] x86 ioctl changes
In general, I'm fine with ignoring things and hoping it works. I
think we should probably change the warn to warn_once.
Similarly, some of the syscalls that we're ignoring should probably
have a warning.
Maybe unimplementedFunc should really just be warn_once plus return error?
Any other opinions?
Nate
The current ioctl implementation is somewhat BSD-centric. The few IOCTL
values being checked have no Linux equivelant. This changes things to
just assume that most ioctl's we'll see are tty related and just return
-ENOTTY. This is enough for spec2k, though obviously not a good idea in
the long run.
diff -r 5ed84199f337 src/arch/x86/linux/syscalls.cc
--- a/src/arch/x86/linux/syscalls.cc Mon Sep 21 23:06:05 2009 -0400
+++ b/src/arch/x86/linux/syscalls.cc Mon Sep 21 23:16:41 2009 -0400
@@ -244,7 +244,7 @@
/* 13 */ SyscallDesc(rt_sigaction, unimplementedFunc),
/* 14 */ SyscallDesc(rt_sigprocmask, ignoreFunc),
/* 15 */ SyscallDesc(rt_sigreturn, unimplementedFunc),
- /* 16 */ SyscallDesc(ioctl, unimplementedFunc),
+ /* 16 */ SyscallDesc(ioctl, ioctlFuncX86Linux64),
/* 17 */ SyscallDesc(pread64, unimplementedFunc),
/* 18 */ SyscallDesc(pwrite64, unimplementedFunc),
/* 19 */ SyscallDesc(readv, unimplementedFunc),
@@ -561,7 +561,7 @@
/* 51 */ SyscallDesc(acct, unimplementedFunc),
/* 52 */ SyscallDesc(umount2, unimplementedFunc),
/* 53 */ SyscallDesc(lock, unimplementedFunc),
- /* 54 */ SyscallDesc(ioctl, unimplementedFunc),
+ /* 54 */ SyscallDesc(ioctl, ioctlFuncX86Linux32),
/* 55 */ SyscallDesc(fcntl, unimplementedFunc),
/* 56 */ SyscallDesc(mpx, unimplementedFunc),
/* 57 */ SyscallDesc(setpgid, unimplementedFunc),
diff -r 5ed84199f337 src/sim/syscall_emul.hh
--- a/src/sim/syscall_emul.hh Mon Sep 21 23:06:05 2009 -0400
+++ b/src/sim/syscall_emul.hh Mon Sep 21 23:16:41 2009 -0400
@@ -486,19 +486,11 @@
}
switch (req) {
- case OS::TIOCISATTY_:
- case OS::TIOCGETP_:
- case OS::TIOCSETP_:
- case OS::TIOCSETN_:
- case OS::TIOCSETC_:
- case OS::TIOCGETC_:
- case OS::TIOCGETS_:
- case OS::TIOCGETA_:
- return -ENOTTY;
default:
- fatal(Unsupported ioctl call: ioctl(%d, 0x%x, ...) @ 0x%llx\n,
+ warn(Unsupported ioctl call: ioctl(%d, 0x%x, ...) @ 0x%llx\n,
fd, req, tc-readPC());
+ return -ENOTTY;
}
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH 4/7] implement time syscall
I did send in a patch for this syscall, yes. I used writeBlob to send the value back to memory. Incidentally, I saw Vince needed ftruncate64 to be implemented. I also sent in a patch for that too. Do you want me to do anything with those patches or can they just be added as they are (do I do that - if so how?) The general rule is that if you're making consistent useful changes, you get commit privileges, but when you're just making small changes, we prefer if you find a committer and work with them to get your changes in the tree. This sometimes requires a bit of persistence on the part of the contributor since there's limited manpower on our part. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] patch/bug tracking
Hi everyone, It seems that we're getting more and more contributions from people and we need a better way to manage patches so they don't get dropped on the floor. The biggest problem is probably that a contributor often doesn't seem to hook up with a specific developer to get a given patch into the tree. Most large open source projects put a substantial burden on the contributor to be persistent and make sure that patches get into the tree, but I wonder if we can come up with some system to streamline things. One starting point is that it's probably time for us to grow up and use the bugtracker a whole lot more than we do. One thought I had was for some way to help users more automatically enter patches into the bug tracking system. In theory, if we put bug numbers into the initial patchbomb message (e.g. the [PATCH 0/7] message), then we could suck all of the resulting patches into the bug database provided that the bug number exists. There's code that does this sort of thing in the mercurial bugzilla extension and it probably wouldn't be too cumbersome to get working with flyspray. The main thing is that I want to come up with a workable idea of how the system should work before I spend any time working on it. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
