Ok. I'll take a look at the microcode.
That's the e-mail I've found:
http://www.mail-archive.com/m5-dev@m5sim.org/msg03671.html
--
Eberle A. Rambo.
On Wed, Jun 30, 2010 at 4:22 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
I vaguely remember that too (removing eaComp), but I don't
I can't find the specification of the micro and macroops for sparc v9. I've
read the SPARCv9 architecture manual and found nothing. Am I missing
something?
--
Eberle A. Rambo.
On Thu, Jul 1, 2010 at 10:33 AM, Eberle rambo.u...@gmail.com wrote:
Ok. I'll take a look at the microcode.
That's
Hi,
It turns out that the readfile bug I posted previously (see below) is a
result of an unimplemented vtophys function: CopyIn reads the file in, but
the virtual address where it should be placed is not translated to a
physical address before sendFunctional is called. This results in a
Microcode isn't part of the architecture so it won't be in that manual.
It's just how we've chosen to implement a few instructions, specifically
block loads and stores. I don't think the problem you're seeing has
anything to do with microcode, though.
Gabe
Eberle wrote:
I can't find the
Okay, in terms of the eaComp(), you should be able to look at how alpha and
mips defined EACOMP (eaComp) and do a similar thing for SPARC.
It looks like formerly that function was declared as part of a subclass to
the memory instructions and the inorder model needed to be able to call it
directly
I think we should figure out whether eaComp should or shouldn't exist
first. Currently it's only used in InOrder. Why is it necessary instead
of using the other, existing mechanisms? I vaguely remember having this
conversation before, but I don't remember who said what, what was
decided, or if we
Yeah, I skipped implementing that so far. The reason the table walker is
the way it is is that it needs to actually cooperate with the memory
system and do real loads/stores, honor timing, etc. For functional
accesses you should be able to write a simpler implementation that just
uses its own
So wouldn't a functional table walker be basically be the same as an
atomic-mode one? I'd think it's only the timing-mode version that
really needs all the explicit state. That is, if you were going to
have two versions, I'd think you'd have a functional/atomic one and a
timing one, not a
So wouldn't a functional table walker be basically be the same as an
atomic-mode one?
I guess I was envisioning a single walker that can handle each type of
access. Walker::start handles both timing and atomic accesses currently,
but the way it updates state could be trouble for atomic (and
On 2010-06-28 17:41:44, Nathan Binkert wrote:
src/python/m5/stats.py, line 62
http://reviews.m5sim.org/r/27/diff/2/?file=618#file618line62
Not sure if it matters at all, but you've changed the order of reset.
Currently, we reset stats and then reset objects. I hope that nothing
10 matches
Mail list logo
