[m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp 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/linux/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/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/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/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/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-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/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/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing passed. See /z/m5/regression/regress-2009-02-17-03:00:01 for details. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] ISA/Register File Discussion
I know nobody likes to read looong emails so I'll try to help in splitting this up this email into 2 parts: 1. Comments on Gabe's idea 2. My proposed solution === Comments on Gabe's Idea === From what I gather from Gabe's writeup, I would say the quick/dirty of what Gabe wants to do is decouple the indexing aspect of register files from the storage of the register files and place those within separate objects (is that right Gabe?). My *guess* to what inspires Gabe to do this is Gabe's experience with the O3 CPU which does not use the ISA-specific, pre-defined register file (defines its own) but needs ISA-specific indexing functions to support more complex ISAs. That gets confusing. Also since the SimpleCPU does use the ISA-specific, pre-defined register file that presents a disconnect in how the CPU Models work across the board (there is one more thing that disconnects that I'll get to in a bit...). While I do see Gabe's points about not placing the burden of register file indexing, additional ISA semantics, and potential renaming on the CPU, I disagree somewhat with the notion that we should split the register file into 2 objects: ISA-specific indexing object and a CPU-defined generic register file storage (I do like the idea of generic reg-files that all CPUs use, which I'll get to in a bit...) For the most part, I think that if you have one object (indexer) whose sole purpose is to provide info for another object (register file), then those objects should be unified since there isnt a heavy enough distinction to argue for separate objects. For instance, an indexing object couldn't do it's job without first knowing how many integer, FP, and misc. registers the register file object has. On the flip side of that, the register file object would be useless without the indexing object giving access to the register file's registers. It also gets more complicated in the multithreading case, since now we have to deal with indexing of shared-system registers. So that's part of the reason why I believe it would be too much work just keeping the books clean for two objects, rather than treating the register file as a black box that you will assume will work correctly given the right inputs. === Korey's Solution === The solution I would argue for is to not further create objects for M5 to maintain but to: (1) Be more stringent about the usage of the objects we do have (e.g. only one path for an instruction to access the register file) (2) Consolidate ISA-specific objects that perform the similar functionality into a base-class object (e.g. the register file) (3) Derive ISA-specific capabilities from that base-class object. (i.e. indexing and system register functionality) The quick/dirty way to say that is let's just use the current objects that we have better. The objects of interests are: ThreadContext, ExecContext, RegFile, DynInst. I would like to do these things to create a consistent, generic interface for instructions and CPUs to interact with registers: - Consolidate the discrepancies in how ExecContext is used in CPU Models: ExecContext is the object that an instruction (DynInst) interfaces with to perform it's function on a CPU model.The SimpleCPU defines it's ExecContext to be a pointer to the actual SimpleCPU object. The O3 defines it's ExecContext to be a pointer to the ThreadContext. InOrder model follows suit. **My solution would be to force all instructions to use a ThreadContext pointer to interact with the CPU**. Allowing an instruction direct access to the CPU forces the pre-processing of thread-specific information to be done in the CPU or the instruction object when it really should always be done in the ThreadContext object. Enforcing consistency there simplifies the programming model and the paths to correctness so to speak. - Consolidate the similar portions of the ISA-specific register files into a base register file that every CPU model and ISA can use: The SimpleCPU model uses the ISA-defined register file, while the O3 defines it's own physical register file. Every ISA provides basic integer/floating point/misc. register file functionality yet defines them separately. Why not just create a register file that can be initialized to an arbitrary # of registers (so the O3 can use it as well the InOrder/SimpleCPU/ and register windowing archs.). Going on with something similar to Gabe's large pool of registers idea, the register file could also be initialized by things like the # number of threads and # of reg. windows so there can be one unified concept of register file for all CPUs/ISAs to use. Inside of that register file object, provide the basic functionality that all ISAs have readIntReg,readFloatReg, etc. - Derive a ISA-specific register files from the base register file object. This would take care of the ISA-specific indexing problem since in the case where a ISA does not want to reg. window it uses the base class functions whereas the more complicated case just derives
Re: [m5-dev] Scons 0.98 build problems...
Have you tried cloning a fresh repo and seeing if it works there?
2009/2/17 Korey Sewell ksew...@umich.edu
Hmmm...Dont know what's going on here.. I just reinstalled mercurial with
no luck...
Can someone post the contents of their build/ALPHA_SE/python/m5/defines.py
file so I can see the differences going on?
On Mon, Feb 16, 2009 at 4:19 PM, nathan binkert n...@binkert.org wrote:
Just looking at the output seems to indicate that you've done
something funny with your mercurial setup. Do you have mq in both
your .hgrc file and in /etc/mercurial?
Nate
2009/2/16 Korey Sewell ksew...@umich.edu:
Hey all,
I am currently unable to build any CPU Model successfully after the
scons
update...0
Other people seem to be doing just fine, so am I missing something?
My error message has something to do with generating a defines.py file:
makeDefinesPyFile([build/ALPHA_SE/python/m5/defines.py],
[{'ALPHA_TLASER':
False, 'FAST_ALLOC_STATS': False, 'FAST_ALLOC_DEBUG': False,
'USE_CHECKER':
False, 'SS_COMPATIBLE_FP': True, 'NO_FAST_ALLOC': False, 'USE_FENV':
True,
'TARGET_ISA': 'alpha', 'FULL_SYSTEM': False, 'USE_MYSQL': False},
extension
'hgext/mq' overrides commands: qheader qnew ^qpop qrestore qapplied
qguard
qclone ^strip qgoto qprev qunapplied ^qrefresh qtop ^qdiff qseries
qcommit|qci qfold qnext qdelete|qremove|qrm ^qimport qselect ^qpush
^qinit
qrename|qmv qsave\nextension 'patchbomb' overrides commands: email\nTag
inorder-thread-context-updates.diff overrides mq patch of the same
name\nTag
qtip overrides mq patch of the same name\nTag qbase overrides mq patch
of
the same name\nTag qparent overrides mq patch of the same
name\nec076c266464
5875 default qtip tip inorder-thread-context-updates.diff qbase])
objectifyPyFile([build/ALPHA_SE/python/m5/defines.py.s],
[build/ALPHA_SE/python/m5/defines.py])
scons: *** [build/ALPHA_SE/python/m5/defines.py.s] Exception
Traceback (most recent call last):
File /usr/lib/scons/SCons/Taskmaster.py, line 222, in execute
self.targets[0].build()
File /usr/lib/scons/SCons/Node/__init__.py, line 372, in build
apply(self.get_executor(), (self,), kw)
File /usr/lib/scons/SCons/Executor.py, line 145, in __call__
return self.do_execute(target, kw)
File /usr/lib/scons/SCons/Executor.py, line 131, in do_execute
status = apply(act, (self.targets, self.get_sources(), env), kw)
File /usr/lib/scons/SCons/Action.py, line 468, in __call__
stat = self.execute(target, source, env)
File /usr/lib/scons/SCons/Action.py, line 846, in execute
result = self.execfunction(target=target, source=rsources, env=env)
File /home/ksewell/m5-fresh/build/ALPHA_SE/SConscript, line 843, in
objectifyPyFile
compiled = compile(src, pysource.debugname, 'exec')
File /home/ksewell/m5-fresh/build/ALPHA_SE/python/m5/defines.py,
line 2
hgRev = 'extension 'hgext/mq' overrides commands: qheader qnew
^qpop
qrestore qapplied qguard qclone ^strip qgoto qprev qunapplied ^qrefresh
qtop
^qdiff qseries qcommit|qci qfold qnext qdelete|qremove|qrm ^qimport
qselect
^qpush ^qinit qrename|qmv qsave
--
--
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science Engineering
University of Michigan
___
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
--
--
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science Engineering
University of Michigan
___
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 0.98 build problems...
I think that the problem is that you've got stuff in your hgrc that is
causing problems. What happens when you do
hg id from the command line? I'm guessing that it will complain.
Nate
2009/2/17 Steve Reinhardt ste...@gmail.com:
Have you tried cloning a fresh repo and seeing if it works there?
2009/2/17 Korey Sewell ksew...@umich.edu
Hmmm...Dont know what's going on here.. I just reinstalled mercurial with
no luck...
Can someone post the contents of their build/ALPHA_SE/python/m5/defines.py
file so I can see the differences going on?
On Mon, Feb 16, 2009 at 4:19 PM, nathan binkert n...@binkert.org wrote:
Just looking at the output seems to indicate that you've done
something funny with your mercurial setup. Do you have mq in both
your .hgrc file and in /etc/mercurial?
Nate
2009/2/16 Korey Sewell ksew...@umich.edu:
Hey all,
I am currently unable to build any CPU Model successfully after the
scons
update...0
Other people seem to be doing just fine, so am I missing something?
My error message has something to do with generating a defines.py file:
makeDefinesPyFile([build/ALPHA_SE/python/m5/defines.py],
[{'ALPHA_TLASER':
False, 'FAST_ALLOC_STATS': False, 'FAST_ALLOC_DEBUG': False,
'USE_CHECKER':
False, 'SS_COMPATIBLE_FP': True, 'NO_FAST_ALLOC': False, 'USE_FENV':
True,
'TARGET_ISA': 'alpha', 'FULL_SYSTEM': False, 'USE_MYSQL': False},
extension
'hgext/mq' overrides commands: qheader qnew ^qpop qrestore qapplied
qguard
qclone ^strip qgoto qprev qunapplied ^qrefresh qtop ^qdiff qseries
qcommit|qci qfold qnext qdelete|qremove|qrm ^qimport qselect ^qpush
^qinit
qrename|qmv qsave\nextension 'patchbomb' overrides commands: email\nTag
inorder-thread-context-updates.diff overrides mq patch of the same
name\nTag
qtip overrides mq patch of the same name\nTag qbase overrides mq patch
of
the same name\nTag qparent overrides mq patch of the same
name\nec076c266464
5875 default qtip tip inorder-thread-context-updates.diff qbase])
objectifyPyFile([build/ALPHA_SE/python/m5/defines.py.s],
[build/ALPHA_SE/python/m5/defines.py])
scons: *** [build/ALPHA_SE/python/m5/defines.py.s] Exception
Traceback (most recent call last):
File /usr/lib/scons/SCons/Taskmaster.py, line 222, in execute
self.targets[0].build()
File /usr/lib/scons/SCons/Node/__init__.py, line 372, in build
apply(self.get_executor(), (self,), kw)
File /usr/lib/scons/SCons/Executor.py, line 145, in __call__
return self.do_execute(target, kw)
File /usr/lib/scons/SCons/Executor.py, line 131, in do_execute
status = apply(act, (self.targets, self.get_sources(), env), kw)
File /usr/lib/scons/SCons/Action.py, line 468, in __call__
stat = self.execute(target, source, env)
File /usr/lib/scons/SCons/Action.py, line 846, in execute
result = self.execfunction(target=target, source=rsources, env=env)
File /home/ksewell/m5-fresh/build/ALPHA_SE/SConscript, line 843, in
objectifyPyFile
compiled = compile(src, pysource.debugname, 'exec')
File /home/ksewell/m5-fresh/build/ALPHA_SE/python/m5/defines.py,
line 2
hgRev = 'extension 'hgext/mq' overrides commands: qheader qnew
^qpop
qrestore qapplied qguard qclone ^strip qgoto qprev qunapplied ^qrefresh
qtop
^qdiff qseries qcommit|qci qfold qnext qdelete|qremove|qrm ^qimport
qselect
^qpush ^qinit qrename|qmv qsave
--
--
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science Engineering
University of Michigan
___
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
--
--
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science Engineering
University of Michigan
___
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] Undelivered Mail Returned to Sender
This is the mail system at host daystrom.m5sim.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system ren...@yahoo.com: host b.mx.mail.yahoo.com[66.196.97.250] said: 553 VS10-RT Possible forgery or deactivated due to abuse (#5.1.1) ren...@yahoo.com (in reply to RCPT TO command) Reporting-MTA: dns; daystrom.m5sim.org X-Postfix-Queue-ID: 3557F158439 X-Postfix-Sender: rfc822; m5-dev@m5sim.org Arrival-Date: Tue, 17 Feb 2009 17:24:51 -0500 (EST) Final-Recipient: rfc822; Ren67v@yahoo.com Action: failed Status: 5.0.0 Remote-MTA: dns; b.mx.mail.yahoo.com Diagnostic-Code: smtp; 553 VS10-RT Possible forgery or deactivated due to abuse (#5.1.1) ren67v@yahoo.com ---BeginMessage--- This address has been used to register a Flyspray account. If you were not expecting this message, please ignore and delete it. Go to the following URL to complete your registration: http://www.m5sim.org/flyspray/index.php?do=registermagic=3e721cc8f6706ab869abc5458d05c3f6 Your confirmation code is: 7auZk036bpUWE ---End Message--- ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Scons 0.98 build problems...
If you read the error message it was the hgext.mq line, not the
others. You should leave the style hook enabled.
Nate
On Tue, Feb 17, 2009 at 7:10 PM, Korey Sewell ksew...@umich.edu wrote:
So I finally got M5 to build with scons 0.98 but I had to remove the
patch-queue lines:
[extensions]
hgext.mq =
patchbomb =
style = /home/ksewell/m5/util/style.py
So for some reason, adding patch-queue to the repo just kills the
build for me...
On Tue, Feb 17, 2009 at 3:18 PM, nathan binkert n...@binkert.org wrote:
I think that the problem is that you've got stuff in your hgrc that is
causing problems. What happens when you do
hg id from the command line? I'm guessing that it will complain.
Nate
2009/2/17 Steve Reinhardt ste...@gmail.com:
Have you tried cloning a fresh repo and seeing if it works there?
2009/2/17 Korey Sewell ksew...@umich.edu
Hmmm...Dont know what's going on here.. I just reinstalled mercurial with
no luck...
Can someone post the contents of their build/ALPHA_SE/python/m5/defines.py
file so I can see the differences going on?
On Mon, Feb 16, 2009 at 4:19 PM, nathan binkert n...@binkert.org wrote:
Just looking at the output seems to indicate that you've done
something funny with your mercurial setup. Do you have mq in both
your .hgrc file and in /etc/mercurial?
Nate
2009/2/16 Korey Sewell ksew...@umich.edu:
Hey all,
I am currently unable to build any CPU Model successfully after the
scons
update...0
Other people seem to be doing just fine, so am I missing something?
My error message has something to do with generating a defines.py file:
makeDefinesPyFile([build/ALPHA_SE/python/m5/defines.py],
[{'ALPHA_TLASER':
False, 'FAST_ALLOC_STATS': False, 'FAST_ALLOC_DEBUG': False,
'USE_CHECKER':
False, 'SS_COMPATIBLE_FP': True, 'NO_FAST_ALLOC': False, 'USE_FENV':
True,
'TARGET_ISA': 'alpha', 'FULL_SYSTEM': False, 'USE_MYSQL': False},
extension
'hgext/mq' overrides commands: qheader qnew ^qpop qrestore qapplied
qguard
qclone ^strip qgoto qprev qunapplied ^qrefresh qtop ^qdiff qseries
qcommit|qci qfold qnext qdelete|qremove|qrm ^qimport qselect ^qpush
^qinit
qrename|qmv qsave\nextension 'patchbomb' overrides commands: email\nTag
inorder-thread-context-updates.diff overrides mq patch of the same
name\nTag
qtip overrides mq patch of the same name\nTag qbase overrides mq patch
of
the same name\nTag qparent overrides mq patch of the same
name\nec076c266464
5875 default qtip tip inorder-thread-context-updates.diff qbase])
objectifyPyFile([build/ALPHA_SE/python/m5/defines.py.s],
[build/ALPHA_SE/python/m5/defines.py])
scons: *** [build/ALPHA_SE/python/m5/defines.py.s] Exception
Traceback (most recent call last):
File /usr/lib/scons/SCons/Taskmaster.py, line 222, in execute
self.targets[0].build()
File /usr/lib/scons/SCons/Node/__init__.py, line 372, in build
apply(self.get_executor(), (self,), kw)
File /usr/lib/scons/SCons/Executor.py, line 145, in __call__
return self.do_execute(target, kw)
File /usr/lib/scons/SCons/Executor.py, line 131, in do_execute
status = apply(act, (self.targets, self.get_sources(), env), kw)
File /usr/lib/scons/SCons/Action.py, line 468, in __call__
stat = self.execute(target, source, env)
File /usr/lib/scons/SCons/Action.py, line 846, in execute
result = self.execfunction(target=target, source=rsources, env=env)
File /home/ksewell/m5-fresh/build/ALPHA_SE/SConscript, line 843, in
objectifyPyFile
compiled = compile(src, pysource.debugname, 'exec')
File /home/ksewell/m5-fresh/build/ALPHA_SE/python/m5/defines.py,
line 2
hgRev = 'extension 'hgext/mq' overrides commands: qheader qnew
^qpop
qrestore qapplied qguard qclone ^strip qgoto qprev qunapplied ^qrefresh
qtop
^qdiff qseries qcommit|qci qfold qnext qdelete|qremove|qrm ^qimport
qselect
^qpush ^qinit qrename|qmv qsave
--
--
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science Engineering
University of Michigan
___
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
--
--
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science Engineering
University of Michigan
___
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
--
--
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science Engineering
University of Michigan
Re: [m5-dev] ISA/Register File Discussion
Thanks for the ideas, Korey. I agree that using our existing objects better (defining what they really represent and then using them consistently according to those definitions) should be a central part of whatever we do. 2009/2/17 Korey Sewell ksew...@umich.edu While I do see Gabe's points about not placing the burden of register file indexing, additional ISA semantics, and potential renaming on the CPU, I disagree somewhat with the notion that we should split the register file into 2 objects: ISA-specific indexing object and a CPU-defined generic register file storage I think the key to Gabe's design is that all that's left of the register file once you've factored out the indexing object is this: TheISA::IntReg regs[TheISA::NumIntRegs]; TheISA::FloatReg regs[TheISA::NumFloatRegs]; so the benefit of defining those two lines in a central place is pretty minimal, and given that at least one CPU model (O3) doesn't use that storage at all, there's no point in requiring it to exist. For the most part, I think that if you have one object (indexer) whose sole purpose is to provide info for another object (register file), then those objects should be unified The key is that the indexer can provide indexes to multiple kinds of register files, flat dumb ones or fancy renaming ones, and so there's no point in hardwiring in the former. It also gets more complicated in the multithreading case, since now we have to deal with indexing of shared-system registers. Yes, this is an issue that needs to be considered, as I mentioned in my previous email. It's not clear that integrating in the register storage makes that any easier though. - Consolidate the discrepancies in how ExecContext is used in CPU Models: ExecContext is the object that an instruction (DynInst) interfaces with to perform it's function on a CPU model.The SimpleCPU defines it's ExecContext to be a pointer to the actual SimpleCPU object. The O3 defines it's ExecContext to be a pointer to the ThreadContext. InOrder model follows suit. **My solution would be to force all instructions to use a ThreadContext pointer to interact with the CPU**. Allowing an instruction direct access to the CPU forces the pre-processing of thread-specific information to be done in the CPU or the instruction object when it really should always be done in the ThreadContext object. Enforcing consistency there simplifies the programming model and the paths to correctness so to speak. I believe that in O3 the ExecContext is the DynInst. The key is that the ExecContext *by definition* is the interface that instructions use to access their execution context. It's got to encapsulate whatever state is required to correctly execute the instruction, which can be not much (for SimpleCPU) or a lot (for O3... note that the DynInst captures where in the speculative instruction flow the instruction exists, so it can get properly renamed registers, etc.). So what you're really saying is that you want to merge the ThreadContext and ExecContext. There are a lot of similarities, but there are differences too; it's helpful to look at BaseSimpleCPU in src/cpu/simple/base.hh, as that's an object that implements the ExecContext interface (most of it, anyway) on top of the ThreadContext interface (provided by SimpleThread). There are a number of calls that pass straight through, but there are several (such as the register accessor instructions) that do not. Note for example that an instruction cannot directly access register 23; there have to be hooks that allow that register to be renamed, and to prevent an instruction from accessing a register that didn't get renamed as one of its operands. However ThreadContext does allow direct register accesses, because it's really a functional interface to the thread's context (similar to how a sendFunctional() access to memory differs from a sendTiming()). Kevin helpfully provided documentation on the wiki for these concepts (which I just found today): http://m5sim.org/wiki/index.php/ExecContext http://m5sim.org/wiki/index.php/ThreadContext http://m5sim.org/wiki/index.php/SimpleThread http://m5sim.org/wiki/index.php/ThreadState - Consolidate the similar portions of the ISA-specific register files into a base register file that every CPU model and ISA can use: I think this is the ISA indexer object that Gabe was talking about... I don't think there's enough similarity in the raw storage to make sharing that across CPU models worthwhile. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] register file revamp
On Feb 17, 2009, at 11:18 PM, Steve Reinhardt wrote: The idea of the merge() step (mapping *all* registers to a single integer namespace) was actually inherited from SimpleScalar; my guess is that the only thing that might really get complicated if we abandon that is register dependency handling in out-of-order models (and maybe inorder too?). Before we take the step of getting rid of that we may want to look at how we'd do those things otherwise. Or perhaps the answer is that CPU models that want to incorporate a merge() mapping are free to do so, but they must do it inside the model and we won't assume it for any external interfaces. One thing we should remember is some ISAs have instructions that cross the register files domains. (e.g. move a float register to an int register or vise-versa). In those cases you definitely need dependence information between them for o3 execution. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
