[m5-dev] Cron <[EMAIL PROTECTED]> /z/m5/regression/do-regression quick

2008-05-22 Thread Cron Daemon 
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* 
build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic 
passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing 
passed.
* build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed.

See /z/m5/regression/regress-2008-05-23-03:00:01 for details.

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] upstream changeset in output

2008-05-22 Thread Ali Saidi 
Well, I imagine most people will use mercurial at least to check out  
the code in which case we'll have the last ID. Perhaps we want to  
include the qbase revision as well incase lot of people use MQ.  
Speaking of which when the repository is made available we probably  
want a pretty good little e-mali tutorial that pitches the "right" way  
to do things as using MQ on top of the repository. I don't really like  
the idea of having a hook that introduces its own changesets into the  
repository. Anything we add needs to be a manipulation of the data in  
the mercurial directory.


Ali



On May 22, 2008, at 8:56 PM, Gabe Black wrote:

As I said in an email earlier, you had pointed out that if somebody  
sends in the output of m5, it's nice to be able to easily tell it's  
beta 4 or beta 3 or somewhere in the middle and they, for instance,  
might need the cache patches without having to go back and forth  
teasing out details. My gut says a lot of people won't take  
advantage of mercurial so the current revision will likely be the  
same as the mainline one, but it might be useful. It could also be  
handy to easily tell what changesets from the mainline you're binary  
was compiled with assuming you have patches on top of it. It's  
something that could be handy although I'm sure we'd survive without  
it.


Gabe

Ali Saidi wrote:

Why do we care about the central repository version?

Ali

On May 22, 2008, at 8:13 PM, Gabe Black wrote:

So anyway, now that we seem to have the current version in there,  
what about the original question which was about the latest  
mainline revision?


Ali Saidi wrote:
That wouldn't be ideal because we would need to emulate  
everything Object() is doing to get the c compiler and options  
right.


Here is take two on the hg version diff. It creates a file which  
is dependent on all the other objects in the system. So if you  
make a change to the repository nothing will be recompiled. To  
get the right info I need to use os.getcwd(). That works in the  
default case but I don't know how it interacts with Nate's  
compiling script. Worst case it just print the Hg revision as  
"Unknown", however I can't seem to pass the SConscript root  
directory to the builder that builds hginfo.cc without it setting  
up a circular dependency that I can't get rid of.



Ali


On May 21, 2008, at 5:47 PM, Nathan Binkert wrote:

We could just provide our own action that is both a file  
generation and a compile.


On May 21, 2008, at 2:05 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:

We can't because the date is created by the compiler with the  
__DATE__ __TIME__ macros. The only way to do something like  
this would be create a dummy file that we write a string to in  
the SConscript. We can set it's dependencies to be all other  
objects, but I don't know if we can remove the dependence on  
itself (it's changed so why shouldn't a new object file be  
created?).


Ali


On May 21, 2008, at 4:59 PM, Nathan Binkert wrote:

What exactly are you trying to do? Stick the changset in the  
output? If so, do it how we do the date.


On May 21, 2008, at 1:12 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:

This diff stamps a file adds the mercurial id to the output,  
however Nate complained that if the revision in the working  
directory changed (which could happen if you qdeleted a  
patch) then you would have to recompile (although not much  
just a re-linking). Something that could fix that (that I  
didn't try) would be to remove the build dependency from that  
file, but you would have to add a dependency to every other  
file in the build that would execute some python that would  
cause that file to regenerated.


Ali




On May 21, 2008, at 4:08 PM, Gabe Black wrote:

I've been thinking about how this could actually be done,  
and it seems to me that there could be a hook in the head  
(hooks are propagated, right?) which adjusted a header file  
every time a changeset was pushed into the head to have that  
hex value in a variable. The adjustment to the header file  
would be part of the changeset so that moving around  
revisions would keep it consistent, and I don't know if you  
could really do it any other way. That would ensure that  
unless the downstream users explicitly modify that header  
file for some reason, which would be a little weird, the  
output would reflect the last changeset that was stamped by  
the root. One downside to all this is that that file would  
change constantly and clutter the history and the repository  
metadata.


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 m

Re: [m5-dev] upstream changeset in output

2008-05-22 Thread Gabe Black 
As I said in an email earlier, you had pointed out that if somebody 
sends in the output of m5, it's nice to be able to easily tell it's beta 
4 or beta 3 or somewhere in the middle and they, for instance, might 
need the cache patches without having to go back and forth teasing out 
details. My gut says a lot of people won't take advantage of mercurial 
so the current revision will likely be the same as the mainline one, but 
it might be useful. It could also be handy to easily tell what 
changesets from the mainline you're binary was compiled with assuming 
you have patches on top of it. It's something that could be handy 
although I'm sure we'd survive without it.


Gabe

Ali Saidi wrote:

Why do we care about the central repository version?

Ali

On May 22, 2008, at 8:13 PM, Gabe Black wrote:

So anyway, now that we seem to have the current version in there, 
what about the original question which was about the latest mainline 
revision?


Ali Saidi wrote:
That wouldn't be ideal because we would need to emulate everything 
Object() is doing to get the c compiler and options right.


Here is take two on the hg version diff. It creates a file which is 
dependent on all the other objects in the system. So if you make a 
change to the repository nothing will be recompiled. To get the 
right info I need to use os.getcwd(). That works in the default case 
but I don't know how it interacts with Nate's compiling script. 
Worst case it just print the Hg revision as "Unknown", however I 
can't seem to pass the SConscript root directory to the builder that 
builds hginfo.cc without it setting up a circular dependency that I 
can't get rid of.



Ali


On May 21, 2008, at 5:47 PM, Nathan Binkert wrote:

We could just provide our own action that is both a file generation 
and a compile.


On May 21, 2008, at 2:05 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:

We can't because the date is created by the compiler with the 
__DATE__ __TIME__ macros. The only way to do something like this 
would be create a dummy file that we write a string to in the 
SConscript. We can set it's dependencies to be all other objects, 
but I don't know if we can remove the dependence on itself (it's 
changed so why shouldn't a new object file be created?).


Ali


On May 21, 2008, at 4:59 PM, Nathan Binkert wrote:

What exactly are you trying to do? Stick the changset in the 
output? If so, do it how we do the date.


On May 21, 2008, at 1:12 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:

This diff stamps a file adds the mercurial id to the output, 
however Nate complained that if the revision in the working 
directory changed (which could happen if you qdeleted a patch) 
then you would have to recompile (although not much just a 
re-linking). Something that could fix that (that I didn't try) 
would be to remove the build dependency from that file, but you 
would have to add a dependency to every other file in the build 
that would execute some python that would cause that file to 
regenerated.


Ali




On May 21, 2008, at 4:08 PM, Gabe Black wrote:

I've been thinking about how this could actually be done, and 
it seems to me that there could be a hook in the head (hooks 
are propagated, right?) which adjusted a header file every time 
a changeset was pushed into the head to have that hex value in 
a variable. The adjustment to the header file would be part of 
the changeset so that moving around revisions would keep it 
consistent, and I don't know if you could really do it any 
other way. That would ensure that unless the downstream users 
explicitly modify that header file for some reason, which would 
be a little weird, the output would reflect the last changeset 
that was stamped by the root. One downside to all this is that 
that file would change constantly and clutter the history and 
the repository metadata.


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



 



___
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] local APIC timer and bus frequency

2008-05-22 Thread Gabe Black 
   I was thinking about this more, and, bus frequency aside, it seems 
like the LAPIC is basically exactly what that interrupts object I made 
in the CPU is for, namely managing interrupts and feeding them one at a 
time on request and according to the ISA's policy to the CPU. At the 
moment that's just a C++ class for the purpose of abstraction if I 
remember right, but it might be good to promote it to a full simobject. 
That limits people's ability to put it in weird places, but they'd 
probably want to do that with the IO APIC (the one the devices actually 
talk to) anyway. This also touches on something I've been thinking 
about, namely that control registers might be more closely associated 
with particular structures like the TLB or the interrupts object or the 
register flattening than with the CPU itself or controlling 
instructions. I was thinking it might be a good idea to set up some sort 
of call back interface on the MiscRegFile so those "devices" can keep 
track of those values more with an interrupt model than a polling model 
which would probably perform much better. The actual storage could be 
moved over to them or not, that's more of an implementation detail, but 
either way it would immediately take care of the performance problems 
with SPARCs register window handling stuff.


Gabe

Steve Reinhardt wrote:



On Thu, May 22, 2008 at 11:45 AM, Gabe Black <[EMAIL PROTECTED] 
> wrote:


One problem is that this isn't a parent/child relationship. For
instance, there could be four CPUs and four local APICs all on the
same bus, and they need to know which one goes with which CPU. In
that case it would be arbitrary. [...] Also, all the local APICs
appear at the same address but are only visible to their CPU. I
was going to try to deal with that by sticking them into their own
address space multiplexed on some address bits, but I don't like
the scalability of that.


Yea, that's the kind of thing I meant by "fiddling with address 
mappings".  I wouldn't disagree that it's a bit hackish, but it seems 
plenty scalable to me.  If you do that it does solve the "all the 
APICs on one local bus" problem too.
 


Another idea is a bus local to the CPU which has the CPU and APIC
on it. That would have to connect to the external interconnect
somehow. That could also be a home for the page table walker and
tlb eventually if those go "off chip" and into the memory system.


The tricky part here is doing that without adding latency to non-APIC 
memory accesses (and appropriately forwarding flow-control state 
through from the cache, etc.).  It's probably doable but it would be 
nicer to have a more general solution that didn't require this (IMO).


If the interconnect isn't a bus, then you can't just stick the
APICs anywhere since they're supposed to be tightly integrated on
die. You'd need to make sure they ended up very close to their
CPUs, and having that over a network hop would be substantially
unrealistic.


Don't forget that part of the point of m5 is to be able to model 
things that are "substantially unrealistic", like putting a PCI NIC 
next to the L2 cache :-).  I think a solution that lets you put the 
APIC wherever you want is a good idea, even if most of those places 
are obviously stupid.
 


I don't think it matters much whether the CPU can check the
interconnect frequency, although it probably can through some
mechanism somewhere like CPUID or the stuff the processor sticks
into PCI config space according to the AMD kernel/BIOS developers
guide. The timer is being setup and used for something, and I
would imagine whatever is using it might break if the frequency is
way off. Then again maybe not. I'd rather make it do what it's
supposed to do than to try to figure out and fix the problems it
may cause later.


I think the key is separating the stuff that needs to be a certain way 
to get things to work from the stuff that is just done a certain way 
just because that's easy/traditional/whatever.  So clearly the APIC 
timer needs to run at a frequency within some range, such that the CPU 
can figure out what that frequency is, but I'm guessing that as long 
as that frequency is reasonable it doesn't matter exactly what it's 
relationship is to the interconnect.  So just having a parameter that 
lets you set the frequency sounds fine to me; if in the longer term we 
find that there really is a need to have it tied to the interconnect 
frequency we can always set that up in the python.


Steve



___
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] upstream changeset in output

2008-05-22 Thread Ali Saidi 

Why do we care about the central repository version?

Ali

On May 22, 2008, at 8:13 PM, Gabe Black wrote:

  So anyway, now that we seem to have the current version in there,  
what about the original question which was about the latest mainline  
revision?


Ali Saidi wrote:
That wouldn't be ideal because we would need to emulate everything  
Object() is doing to get the c compiler and options right.


Here is take two on the hg version diff. It creates a file which is  
dependent on all the other objects in the system. So if you make a  
change to the repository nothing will be recompiled. To get the  
right info I need to use os.getcwd(). That works in the default  
case but I don't know how it interacts with Nate's compiling  
script. Worst case it just print the Hg revision as "Unknown",  
however I can't seem to pass the SConscript root directory to the  
builder that builds hginfo.cc without it setting up a circular  
dependency that I can't get rid of.



Ali


On May 21, 2008, at 5:47 PM, Nathan Binkert wrote:

We could just provide our own action that is both a file  
generation and a compile.


On May 21, 2008, at 2:05 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:

We can't because the date is created by the compiler with the  
__DATE__ __TIME__ macros. The only way to do something like this  
would be create a dummy file that we write a string to in the  
SConscript. We can set it's dependencies to be all other objects,  
but I don't know if we can remove the dependence on itself (it's  
changed so why shouldn't a new object file be created?).


Ali


On May 21, 2008, at 4:59 PM, Nathan Binkert wrote:

What exactly are you trying to do?  Stick the changset in the  
output?  If so, do it how we do the date.


On May 21, 2008, at 1:12 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:

This diff stamps a file adds the mercurial id to the output,  
however Nate complained that if the revision in the working  
directory changed (which could happen if you qdeleted a patch)  
then you would have to recompile (although not much just a re- 
linking). Something that could fix that (that I didn't try)  
would be to remove the build dependency from that file, but you  
would have to add a dependency to every other file in the build  
that would execute some python that would cause that file to  
regenerated.


Ali




On May 21, 2008, at 4:08 PM, Gabe Black wrote:

I've been thinking about how this could actually be done, and  
it seems to me that there could be a hook in the head (hooks  
are propagated, right?) which adjusted a header file every  
time a changeset was pushed into the head to have that hex  
value in a variable. The adjustment to the header file would  
be part of the changeset so that moving around revisions would  
keep it consistent, and I don't know if you could really do it  
any other way. That would ensure that unless the downstream  
users explicitly modify that header file for some reason,  
which would be a little weird, the output would reflect the  
last changeset that was stamped by the root. One downside to  
all this is that that file would change constantly and clutter  
the history and the repository metadata.


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





___
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] upstream changeset in output

2008-05-22 Thread Gabe Black 
   So anyway, now that we seem to have the current version in there, 
what about the original question which was about the latest mainline 
revision?


Ali Saidi wrote:
That wouldn't be ideal because we would need to emulate everything 
Object() is doing to get the c compiler and options right.


Here is take two on the hg version diff. It creates a file which is 
dependent on all the other objects in the system. So if you make a 
change to the repository nothing will be recompiled. To get the right 
info I need to use os.getcwd(). That works in the default case but I 
don't know how it interacts with Nate's compiling script. Worst case 
it just print the Hg revision as "Unknown", however I can't seem to 
pass the SConscript root directory to the builder that builds 
hginfo.cc without it setting up a circular dependency that I can't get 
rid of.



Ali


On May 21, 2008, at 5:47 PM, Nathan Binkert wrote:

We could just provide our own action that is both a file generation 
and a compile.


On May 21, 2008, at 2:05 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:

We can't because the date is created by the compiler with the 
__DATE__ __TIME__ macros. The only way to do something like this 
would be create a dummy file that we write a string to in the 
SConscript. We can set it's dependencies to be all other objects, 
but I don't know if we can remove the dependence on itself (it's 
changed so why shouldn't a new object file be created?).


Ali


On May 21, 2008, at 4:59 PM, Nathan Binkert wrote:

What exactly are you trying to do?  Stick the changset in the 
output?  If so, do it how we do the date.


On May 21, 2008, at 1:12 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:

This diff stamps a file adds the mercurial id to the output, 
however Nate complained that if the revision in the working 
directory changed (which could happen if you qdeleted a patch) 
then you would have to recompile (although not much just a 
re-linking). Something that could fix that (that I didn't try) 
would be to remove the build dependency from that file, but you 
would have to add a dependency to every other file in the build 
that would execute some python that would cause that file to 
regenerated.


Ali




On May 21, 2008, at 4:08 PM, Gabe Black wrote:

I've been thinking about how this could actually be done, and it 
seems to me that there could be a hook in the head (hooks are 
propagated, right?) which adjusted a header file every time a 
changeset was pushed into the head to have that hex value in a 
variable. The adjustment to the header file would be part of the 
changeset so that moving around revisions would keep it 
consistent, and I don't know if you could really do it any other 
way. That would ensure that unless the downstream users 
explicitly modify that header file for some reason, which would 
be a little weird, the output would reflect the last changeset 
that was stamped by the root. One downside to all this is that 
that file would change constantly and clutter the history and the 
repository metadata.


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





___
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] HG: Add compiled hg revision and date to the standard M5 output

2008-05-22 Thread Ali Saidi 
So this fixes some bugs in the previous version (specifically  
hginfo.cc being dependent on all variants of all objects and it seems  
to work with Nate's compile script).


Any problems or should I commit it?

Ali


On May 22, 2008, at 5:02 PM, Ali Saidi wrote:


# HG changeset patch
# User Ali Saidi <[EMAIL PROTECTED]>
# Date 1211490125 14400
# Node ID b9683f2d6b0cb9288bc5f107b193ee617310fce8
# Parent  fc6b6643b9c611ee5367a3db99b0705e74d9b06d
HG: Add compiled hg revision and date to the standard M5 output.

diff --git a/src/SConscript b/src/SConscript
--- a/src/SConscript
+++ b/src/SConscript
@@ -333,6 +333,15 @@ env.Command('base/traceflags.cc', flags,
env.Command('base/traceflags.cc', flags, generate.traceFlagsCC)
Source('base/traceflags.cc')

+# Generate hginfo.cc
+# Anything we pass as a source gets setup as a dependence so rather  
than
+#  passing the SConscript/hg dir/etc we just squirrel away the  
SConstruct

+#  directory in the environment and retrieve it later. This seems to
+#  be the only reliable way to get the information if we're  
building in

+#  a directory outside of the m5 directory
+env['SConstructDir'] = str(SCons.Node.FS.default_fs.SConstruct_dir)
+env.Command('base/hginfo.cc', None, generate.hgInfo)
+
# Build the zip file
py_compiled = []
py_zip_depends = []
@@ -365,11 +374,20 @@ envList = []
# date.cc.
def make_objs(sources, env):
objs = [env.Object(s) for s in sources]
+
# make date.cc depend on all other objects so it always gets
# recompiled whenever anything else does
date_obj = env.Object('base/date.cc')
+
+# Abuse the SCons dependence code to make the generation
+# of hginfo.cc dependend on all the other cc files and the
+# compiling of hginfo.cc dependent on all the objects
+# but hginfo.o
+hg_obj = env.Object('base/hginfo.cc')
+env.Depends('base/hginfo.cc', sources)
env.Depends(date_obj, objs)
-objs.append(date_obj)
+env.Depends(hg_obj, objs)
+objs.extend([date_obj,hg_obj])
return objs

# Function to create a new build environment as clone of current
diff --git a/src/python/generate.py b/src/python/generate.py
--- a/src/python/generate.py
+++ b/src/python/generate.py
@@ -32,8 +32,7 @@ import sys
import sys
import zipfile

-from os.path import basename
-from os.path import exists
+from os.path import basename, exists, isdir, join

class DictImporter(object):
'''This importer takes a dictionary of arbitrary module names that
@@ -528,3 +527,39 @@ extern const Flags *compoundFlags[];
'''

f.close()
+
+def hgInfo(self, target, source, env):
+try:
+# The SConscript squirrels away the SConstructDir  
variable in the
+# env for us. We can't pass it as a source parameter  
because that
+# would setup a depedence between everything in the  
directory and

+# above and this file.
+
+scons_dir = env['SConstructDir']
+import  mercurial.hg, mercurial.ui, mercurial.util,  
mercurial.node

+if not exists(scons_dir) or not isdir(scons_dir) or \
+   not exists(join(scons_dir, ".hg")):
+raise ValueError
+repo = mercurial.hg.repository(mercurial.ui.ui(),  
scons_dir)

+rev = mercurial.node.nullrev + repo.changelog.count()
+changenode = repo.changelog.node(rev)
+changes = repo.changelog.read(changenode)
+date = mercurial.util.datestr(changes[2])
+
+hg_stats = file(str(target[0]), 'w')
+print >>hg_stats, 'const char *hgRev = "%s:%s";' %   
(rev, mercurial.node.hex(changenode))

+print >>hg_stats, 'const char *hgDate = "%s";' % date
+hg_stats.close()
+mercurial.demandimport.disable()
+except ImportError:
+pass
+except:
+hg_stats = file(str(target[0]), 'w')
+print >>hg_stats, 'const char *hgRev = "Unknown";'
+print >>hg_stats, 'const char *hgDate = "Unknown";'
+hg_stats.close()
+mercurial.demandimport.disable()
+
+
+
+
diff --git a/src/python/m5/main.py b/src/python/m5/main.py
--- a/src/python/m5/main.py
+++ b/src/python/m5/main.py
@@ -269,6 +269,10 @@ def main():
print "M5 compiled %s" % internal.core.cvar.compileDate;
print "M5 started %s" % datetime.datetime.now().ctime()
print "M5 executing on %s" % socket.gethostname()
+
+print "M5 revision %s" % internal.core.cvar.hgRev
+print "M5 commit date %s" % internal.core.cvar.hgDate
+
print "command line:",
for argv in sys.argv:
print argv,
diff --git a/src/python/swig/core.i b/src/python/swig/core.i
--- a/src/python/swig/core.i
+++ b/src/python/swig/core.i
@@ -39,6 +39,8 @@
#include "sim/startup.hh"

extern const char *compileDate;
+extern const char *hgRev;
+extern const char *hgDate;
%}

%include "stdint.i"
@@ -51,6 +53,8 @@ void doExitCleanup();
void doExitCleanup();

char *

[m5-dev] [PATCH] HG: Add compiled hg revision and date to the standard M5 output

2008-05-22 Thread Ali Saidi 
# HG changeset patch
# User Ali Saidi <[EMAIL PROTECTED]>
# Date 1211490125 14400
# Node ID b9683f2d6b0cb9288bc5f107b193ee617310fce8
# Parent  fc6b6643b9c611ee5367a3db99b0705e74d9b06d
HG: Add compiled hg revision and date to the standard M5 output.

diff --git a/src/SConscript b/src/SConscript
--- a/src/SConscript
+++ b/src/SConscript
@@ -333,6 +333,15 @@ env.Command('base/traceflags.cc', flags,
 env.Command('base/traceflags.cc', flags, generate.traceFlagsCC)
 Source('base/traceflags.cc')
 
+# Generate hginfo.cc
+# Anything we pass as a source gets setup as a dependence so rather than
+#  passing the SConscript/hg dir/etc we just squirrel away the SConstruct
+#  directory in the environment and retrieve it later. This seems to 
+#  be the only reliable way to get the information if we're building in
+#  a directory outside of the m5 directory 
+env['SConstructDir'] = str(SCons.Node.FS.default_fs.SConstruct_dir)
+env.Command('base/hginfo.cc', None, generate.hgInfo)
+
 # Build the zip file
 py_compiled = []
 py_zip_depends = []
@@ -365,11 +374,20 @@ envList = []
 # date.cc.
 def make_objs(sources, env):
 objs = [env.Object(s) for s in sources]
+  
 # make date.cc depend on all other objects so it always gets
 # recompiled whenever anything else does
 date_obj = env.Object('base/date.cc')
+
+# Abuse the SCons dependence code to make the generation
+# of hginfo.cc dependend on all the other cc files and the
+# compiling of hginfo.cc dependent on all the objects
+# but hginfo.o 
+hg_obj = env.Object('base/hginfo.cc')
+env.Depends('base/hginfo.cc', sources)
 env.Depends(date_obj, objs)
-objs.append(date_obj)
+env.Depends(hg_obj, objs)
+objs.extend([date_obj,hg_obj])
 return objs
 
 # Function to create a new build environment as clone of current
diff --git a/src/python/generate.py b/src/python/generate.py
--- a/src/python/generate.py
+++ b/src/python/generate.py
@@ -32,8 +32,7 @@ import sys
 import sys
 import zipfile
 
-from os.path import basename
-from os.path import exists
+from os.path import basename, exists, isdir, join
 
 class DictImporter(object):
 '''This importer takes a dictionary of arbitrary module names that
@@ -528,3 +527,39 @@ extern const Flags *compoundFlags[];
 '''
 
 f.close()
+
+def hgInfo(self, target, source, env):
+try:
+# The SConscript squirrels away the SConstructDir variable in the
+# env for us. We can't pass it as a source parameter because that 
+# would setup a depedence between everything in the directory and
+# above and this file. 
+
+scons_dir = env['SConstructDir']
+import  mercurial.hg, mercurial.ui, mercurial.util, mercurial.node
+if not exists(scons_dir) or not isdir(scons_dir) or \
+   not exists(join(scons_dir, ".hg")):
+raise ValueError
+repo = mercurial.hg.repository(mercurial.ui.ui(), scons_dir)
+rev = mercurial.node.nullrev + repo.changelog.count()
+changenode = repo.changelog.node(rev)
+changes = repo.changelog.read(changenode)
+date = mercurial.util.datestr(changes[2])
+
+hg_stats = file(str(target[0]), 'w')
+print >>hg_stats, 'const char *hgRev = "%s:%s";' %  (rev, 
mercurial.node.hex(changenode))
+print >>hg_stats, 'const char *hgDate = "%s";' % date
+hg_stats.close()
+mercurial.demandimport.disable()
+except ImportError:
+pass
+except:
+hg_stats = file(str(target[0]), 'w')
+print >>hg_stats, 'const char *hgRev = "Unknown";'
+print >>hg_stats, 'const char *hgDate = "Unknown";'
+hg_stats.close()
+mercurial.demandimport.disable()
+
+
+
+
diff --git a/src/python/m5/main.py b/src/python/m5/main.py
--- a/src/python/m5/main.py
+++ b/src/python/m5/main.py
@@ -269,6 +269,10 @@ def main():
 print "M5 compiled %s" % internal.core.cvar.compileDate;
 print "M5 started %s" % datetime.datetime.now().ctime()
 print "M5 executing on %s" % socket.gethostname()
+
+print "M5 revision %s" % internal.core.cvar.hgRev
+print "M5 commit date %s" % internal.core.cvar.hgDate
+
 print "command line:",
 for argv in sys.argv:
 print argv,
diff --git a/src/python/swig/core.i b/src/python/swig/core.i
--- a/src/python/swig/core.i
+++ b/src/python/swig/core.i
@@ -39,6 +39,8 @@
 #include "sim/startup.hh"
 
 extern const char *compileDate;
+extern const char *hgRev;
+extern const char *hgDate;
 %}
 
 %include "stdint.i"
@@ -51,6 +53,8 @@ void doExitCleanup();
 void doExitCleanup();
 
 char *compileDate;
+char *hgRev;
+char *hgDate;
 
 void setClockFrequency(Tick ticksPerSecond);
 
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

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

2008-05-22 Thread Steve Reinhardt 
On Thu, May 22, 2008 at 11:45 AM, Gabe Black <[EMAIL PROTECTED]> wrote:

> One problem is that this isn't a parent/child relationship. For instance,
> there could be four CPUs and four local APICs all on the same bus, and they
> need to know which one goes with which CPU. In that case it would be
> arbitrary. [...] Also, all the local APICs appear at the same address but
> are only visible to their CPU. I was going to try to deal with that by
> sticking them into their own address space multiplexed on some address bits,
> but I don't like the scalability of that.


Yea, that's the kind of thing I meant by "fiddling with address mappings".
I wouldn't disagree that it's a bit hackish, but it seems plenty scalable to
me.  If you do that it does solve the "all the APICs on one local bus"
problem too.


> Another idea is a bus local to the CPU which has the CPU and APIC on it.
> That would have to connect to the external interconnect somehow. That could
> also be a home for the page table walker and tlb eventually if those go "off
> chip" and into the memory system.


The tricky part here is doing that without adding latency to non-APIC memory
accesses (and appropriately forwarding flow-control state through from the
cache, etc.).  It's probably doable but it would be nicer to have a more
general solution that didn't require this (IMO).

If the interconnect isn't a bus, then you can't just stick the APICs
> anywhere since they're supposed to be tightly integrated on die. You'd need
> to make sure they ended up very close to their CPUs, and having that over a
> network hop would be substantially unrealistic.


Don't forget that part of the point of m5 is to be able to model things that
are "substantially unrealistic", like putting a PCI NIC next to the L2 cache
:-).  I think a solution that lets you put the APIC wherever you want is a
good idea, even if most of those places are obviously stupid.


> I don't think it matters much whether the CPU can check the interconnect
> frequency, although it probably can through some mechanism somewhere like
> CPUID or the stuff the processor sticks into PCI config space according to
> the AMD kernel/BIOS developers guide. The timer is being setup and used for
> something, and I would imagine whatever is using it might break if the
> frequency is way off. Then again maybe not. I'd rather make it do what it's
> supposed to do than to try to figure out and fix the problems it may cause
> later.
>

I think the key is separating the stuff that needs to be a certain way to
get things to work from the stuff that is just done a certain way just
because that's easy/traditional/whatever.  So clearly the APIC timer needs
to run at a frequency within some range, such that the CPU can figure out
what that frequency is, but I'm guessing that as long as that frequency is
reasonable it doesn't matter exactly what it's relationship is to the
interconnect.  So just having a parameter that lets you set the frequency
sounds fine to me; if in the longer term we find that there really is a need
to have it tied to the interconnect frequency we can always set that up in
the python.

Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

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

2008-05-22 Thread Gabe Black 
One problem is that this isn't a parent/child relationship. For 
instance, there could be four CPUs and four local APICs all on the same 
bus, and they need to know which one goes with which CPU. In that case 
it would be arbitrary. If the interconnect isn't a bus, then you can't 
just stick the APICs anywhere since they're supposed to be tightly 
integrated on die. You'd need to make sure they ended up very close to 
their CPUs, and having that over a network hop would be substantially 
unrealistic. Also, all the local APICs appear at the same address but 
are only visible to their CPU. I was going to try to deal with that by 
sticking them into their own address space multiplexed on some address 
bits, but I don't like the scalability of that. Another idea is a bus 
local to the CPU which has the CPU and APIC on it. That would have to 
connect to the external interconnect somehow. That could also be a home 
for the page table walker and tlb eventually if those go "off chip" and 
into the memory system. I don't think it matters much whether the CPU 
can check the interconnect frequency, although it probably can through 
some mechanism somewhere like CPUID or the stuff the processor sticks 
into PCI config space according to the AMD kernel/BIOS developers guide. 
The timer is being setup and used for something, and I would imagine 
whatever is using it might break if the frequency is way off. Then again 
maybe not. I'd rather make it do what it's supposed to do than to try to 
figure out and fix the problems it may cause later.


Gabe

Steve Reinhardt wrote:



On Wed, May 21, 2008 at 5:44 PM, Gabe Black <[EMAIL PROTECTED] 
> wrote:


  The kernel is now getting to a point where it's trying to
calibrate the timer in the local APIC against the TSC register. In
order to mimic that, I'm going to need to create an event to fire
when the timer is supposed to go off. This is enough of an impetus
to separate the local APIC into it's own device on the bus just
outside of the CPU. That means I need to solve some issues I've
been putting off, namely making sure there's exactly one local
APIC per cpu and that they know about each other. One topology is
that the local APIC acts as an intermediary between the CPU and
the interconnect, and the other is with the APIC as a peer. The
latter won't work so well with non-bus interconnects I don't think.


Why do you say that?  Is there some aspect to how it's addressed that 
makes it different from a regular memory-mapped device?  (In 
particular, some aspect that's not easily worked around by fiddling 
with address mappings?)
 


Also, each APIC has to know what CPU it's associated with so it
can return the right ID number and to have a pointer to make it
interrupt.


Seems like that should be relatively easy to take care of in python 
with a Parent.any parameter.
 


Also, the APIC needs to know what the frequency is of the
interconnect it's connected to since it runs it's timer off of a
divided version of that clock. What do people think?


Is it really architecturally visible that the timer's clock is related 
to the interconnect clock?


Steve



___
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] local APIC timer and bus frequency

2008-05-22 Thread Steve Reinhardt 
On Wed, May 21, 2008 at 5:44 PM, Gabe Black <[EMAIL PROTECTED]> wrote:

>   The kernel is now getting to a point where it's trying to calibrate the
> timer in the local APIC against the TSC register. In order to mimic that,
> I'm going to need to create an event to fire when the timer is supposed to
> go off. This is enough of an impetus to separate the local APIC into it's
> own device on the bus just outside of the CPU. That means I need to solve
> some issues I've been putting off, namely making sure there's exactly one
> local APIC per cpu and that they know about each other. One topology is that
> the local APIC acts as an intermediary between the CPU and the interconnect,
> and the other is with the APIC as a peer. The latter won't work so well with
> non-bus interconnects I don't think.


Why do you say that?  Is there some aspect to how it's addressed that makes
it different from a regular memory-mapped device?  (In particular, some
aspect that's not easily worked around by fiddling with address mappings?)


> Also, each APIC has to know what CPU it's associated with so it can return
> the right ID number and to have a pointer to make it interrupt.


Seems like that should be relatively easy to take care of in python with a
Parent.any parameter.


> Also, the APIC needs to know what the frequency is of the interconnect it's
> connected to since it runs it's timer off of a divided version of that
> clock. What do people think?
>

Is it really architecturally visible that the timer's clock is related to
the interconnect clock?

Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev