Re: [m5-dev] SPARC_SE and InOrderCPU

[Gabriel Michael Black]

I just wanted to make sure we'd thought about whether we wanted eaComp  
so that we'd either implement it entirely or remove it entirely and  
not wander back and forth. It sounds like we want it (could it even  
help with the store-and-update dependency thing that came up  
recently?), so yes, based on that we should probably add support to  
SPARC. I'm not crazy about treating it as a separate instruction since  
that seems like a lot of extra complexity. I think it'd be worthwhile  
to maybe see if we can come up with something that solves all the  
various problems that have come up at once rather than trying to patch  
what's there, but I don't have any ideas of what that would look like.

Gabe
Quoting Steve Reinhardt <ste...@gmail.com>:

Yea, eaComp and memAcc date back to our original SimpleScalar-based
out-of-order pipeline that split out the EA computation so it could
use it for memory scheduling.  When we switched over to the O3 model,
we needed to change this interface to support real split-transaction
memory accesses (i.e., split memAcc into initiateAcc and completeAcc).
 It just happens that O3 uses store sets for memory scheduling, so you
don't need the separate EA computation, so when we added the new
interface we just folded the EA computation into initiateAcc.

The other tricky thing about eaComp (and the reason it gets split out
as a separate instruction object) is that its input dependencies can
be different... that is, on a store, you can do the eaComp before the
store value is available (unlike initiateAcc, which has the same input
dependencies as the overall instruction).

Ha, now that I wrote all this I went back to find the email you
mention in the email you link (about the bug), and there was quite a
bit of discussion there, including this similar recap from me:

http://www.mail-archive.com/m5-dev@m5sim.org/msg03055.html

It's worth reading the rest of that thread too, though apparently we
didn't come to any firm conclusions.

Another twist to throw in the mix (that we weren't aware of in the
previous discussion) is the ugly complexity of split-transaction
address translations necessary for ISAs that have hardware page-table
walkers to run in timing mode (hmm, I sense a convergence of threads
here).  I wonder if there might not be some solution that makes those
less ugly too.  Note that these split-transaction translations have
already complicated TimingSimpleCPU pretty noticeably, and AFAIK no
one has even attempted to see what they'll do to O3.  A separate
eaComp() step might make that a little cleaner.

So it seems like the real issue here is that SPARC doesn't implement
eaComp, is that correct?  So then the question is whether we should
just have SPARC implement eaComp as it is, or should we define a new
interface for all the ISAs?

Steve

On Thu, Jul 1, 2010 at 11:33 AM, Korey Sewell <ksew...@umich.edu> wrote:
This is the original email I sent to m5-dev a while back (with no response I
might add!):
http://www.mail-archive.com/m5-dev@m5sim.org/msg03044.html

The summary is the M5 models currently use initiateAcc and completeAcc to do
memory access. eaComp and memAcc weren't being used.

In initiateAcc, the EA code is included in the function call.

But the inorder model wants to be able to generate the EA independent of
actually doing the memory access.

Thus, the code had to be separated out of just initiateAcc.

There does seem to be some double-work in that initiateAcc does get called
again anyway and recalculates the EA (but we would have to make a
'memAccess' function there to fully separate the case where you are just
doing an independent memory access without the EA calculation).

On Thu, Jul 1, 2010 at 1:46 PM, Gabe Black <gbl...@eecs.umich.edu> wrote:

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 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
> <mailto:rambo.u...@gmail.com>> wrote:
>
>     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 <mailto:gbl...@eecs.umich.edu>> wrote:
>
>         I vaguely remember that too (removing eaComp), but I don't
>         remember the specifics. I think, before InOrder apparently
>         started using it, that that was dead code floating around, but
>         I may be misremembering. I also vaguely remember there was
>         some discussion of why that was necessary for InOrder, but I
>         remember that even less.
>
>         Gabe
>
>
>         Quoting Korey Sewell <ksew...@umich.edu
>         <mailto:ksew...@umich.edu>>:
>
>             Can you post the link for the message saying that eaComp
>             was to be removed?
>             I dont remember the whole discussion offhand.
>
>             In any case, the eaComp is generated for instructions that
>             need to calculate
>             the effective address for the memory calculation. So it
>             sounds to me that
>             there is an instruction being executed that is tagged as
>             memory op. but may
>             not be and when the model wants to calculate the effective
>             address with that
>             instruction, it's panicking.
>
>             What I would do is build a "m5.opt" version of M5 and run
>             the code with the
>             "InOrderCPUAll" traceflags and also separately with the
>             "Exec" flag. The
>             flags traces will help you identify at exactly what point
>             the code broke and
>             give you the appropriate debug messages to solve the
>             problem (you could also
>             use GDB if the function trace is just of interest to you).
>
>             I'm not familiar with SPARC but the issue may also be with
>             support for
>             microcode so if you didnt add any support for that in
>             there and the 1st
>             instruction (i'm assuming since its cycle 59500) needs
>             micro-ops generated
>             then that could also be a problem.
>
>             On Wed, Jun 30, 2010 at 1:10 PM, Eberle
>             <rambo.u...@gmail.com <mailto:rambo.u...@gmail.com>> wrote:
>
>                 I got the SPARC InOrderCPU to compile. But now this is
>                 happening:
>
>                 M5 compiled Jun 30 2010 12:26:11
>
>                 M5 revision edde97a6ea7c+ 7069+ default tip
>                 M5 started Jun 30 2010 12:27:30
>
>                 M5 executing on bellatrix
>                 command line: ./build/SPARC_SE/m5.fast
>                 configs/example/se.py -n 2 --inorder
>                 --caches --l2cache -c meu/hello
>                 Global frequency set at 1000000000000 ticks per second
>                 0: system.remote_gdb.listener: listening for remote
>                 gdb on port 7000
>                 0: system.remote_gdb.listener: listening for remote
>                 gdb on port 7001
>                 **** REAL SIMULATION ****
>                 info: Entering event queue @ 0.  Starting simulation...
>                 panic: eaComp not defined!
>                  @ cycle 59500
>                 [eaComp:build/SPARC_SE/cpu/static_inst_exec_sigs.hh,
>                 line 18]
>                 Memory Usage: 581288 KBytes
>                 For more information see:
>                 http://www.m5sim.org/panic/b960c21d
>                 Program aborted at cycle 59500
>                 Aborted
>
>
>                 I've read that eaComp was removed from Mips and Alpha
>                 and should be removed
>                 from the others too.
>                 What has to be changed?
>
>                 Thanks,
>
>                 --
>                 Eberle A. Rambo.
>
>
>
>                 On Wed, Jun 23, 2010 at 3:40 PM, Korey Sewell
>                 <ksew...@umich.edu <mailto:ksew...@umich.edu>> wrote:
>
>                     oh,
>                     if you do get into developing SPARC support for
>                     the inorder model, let's
>                     move the discussion to the m5-dev@m5sim.org
>                     <mailto:m5-dev@m5sim.org> list which would be the
> more
>                     appropriate discussion board.
>
>
>                     On Wed, Jun 23, 2010 at 11:58 AM, Eberle
>                     <rambo.u...@gmail.com
>                     <mailto:rambo.u...@gmail.com>> wrote:
>
>                         I tried and I get a compilation error:
>
>                         g++ -o
>
> build/SPARC_SE/cpu/inorder/inorder_cpu_builder.fo
>                         <http://inorder_cpu_builder.fo> -c
>                         -Wno-deprecated -pipe -fno-strict-aliasing
>                         -Wall -Wno-sign-compare -Wundef
>                         -O3 -Werror -DNDEBUG -DTRACING_ON=0
>                         -Ibuild/gzstream -Ibuild/libelf -Iext
>                         -I/usr/include/python2.6 -Ibuild/SPARC_SE
>
> build/SPARC_SE/cpu/inorder/inorder_cpu_builder.cc
>                         In file included from
>
> build/SPARC_SE/cpu/inorder/inorder_dyn_inst.hh:42,
>                                         from
>                         build/SPARC_SE/cpu/inorder/cpu.hh:52,
>                                         from
>
> build/SPARC_SE/cpu/inorder/inorder_dyn_inst.cc:42:
>                         build/SPARC_SE/arch/mt.hh:1:28: error:
>                         arch/sparc/mt.hh: No such file or
>                         directory
>                         In file included from
>
> build/SPARC_SE/cpu/inorder/inorder_dyn_inst.hh:42,
>                                         from
>
> build/SPARC_SE/cpu/inorder/pipeline_traits.cc:33:
>                         build/SPARC_SE/arch/mt.hh:1:28: error:
>                         arch/sparc/mt.hh: No such file or
>                         directory
>                         In file included from
>
> build/SPARC_SE/cpu/inorder/inorder_dyn_inst.hh:42,
>                                         from
>                         build/SPARC_SE/cpu/inorder/cpu.hh:52,
>                                         from
>
> build/SPARC_SE/cpu/inorder/inorder_cpu_builder.cc:37:
>                         build/SPARC_SE/arch/mt.hh:1:28: error:
>                         arch/sparc/mt.hh: No such file or
>                         directory
>                         g++ -o
>                         build/SPARC_SE/cpu/inorder/inorder_trace.fo
>                         <http://inorder_trace.fo> -c -Wno-deprecated
>                         -pipe -fno-strict-aliasing -Wall
>                         -Wno-sign-compare -Wundef -O3 -Werror
>                         -DNDEBUG -DTRACING_ON=0 -Ibuild/gzstream
>                         -Ibuild/libelf -Iext
>                         -I/usr/include/python2.6 -Ibuild/SPARC_SE
>                         build/SPARC_SE/cpu/inorder/inorder_trace.cc
>                         g++ -o
>                         build/SPARC_SE/cpu/inorder/pipeline_stage.fo
>                         <http://pipeline_stage.fo> -c -Wno-deprecated
>                         -pipe -fno-strict-aliasing -Wall
>                         -Wno-sign-compare -Wundef -O3 -Werror
>                         -DNDEBUG -DTRACING_ON=0 -Ibuild/gzstream
>                         -Ibuild/libelf -Iext
>                         -I/usr/include/python2.6 -Ibuild/SPARC_SE
>                         build/SPARC_SE/cpu/inorder/pipeline_stage.cc
>                         In file included from
>                         build/SPARC_SE/cpu/inorder/cpu.hh:56,
>                                         from
>
> build/SPARC_SE/cpu/inorder/inorder_dyn_inst.cc:42:
>                         build/SPARC_SE/cpu/inorder/reg_dep_map.hh:49:
>                         error: 'TotalNumRegs' is
>                         not a member of 'SparcISA'
>                         In file included from
>
> build/SPARC_SE/cpu/inorder/inorder_dyn_inst.hh:42,
>                                         from
>                         build/SPARC_SE/cpu/inorder/pipeline_stage.hh:40,
>                                         from
>                         build/SPARC_SE/cpu/inorder/pipeline_stage.cc:34:
>                         build/SPARC_SE/arch/mt.hh:1:28: error:
>                         arch/sparc/mt.hh: No such file or
>                         directory
>                         build/SPARC_SE/cpu/inorder/inorder_dyn_inst.cc:
>                         In member function
>                         'virtual SparcISA::MiscReg
>                         InOrderDynInst::readRegOtherThread(unsigned int,
>                         ThreadID)':
>
> build/SPARC_SE/cpu/inorder/inorder_dyn_inst.cc:516:
>                         error:
>                         'getTargetThread' is not a member of 'SparcISA'
>                         build/SPARC_SE/cpu/inorder/inorder_dyn_inst.cc:
>                         In member function
>                         'virtual void
>                         InOrderDynInst::setRegOtherThread(unsigned
>                         int, const
>                         SparcISA::MiscReg&, ThreadID)':
>
> build/SPARC_SE/cpu/inorder/inorder_dyn_inst.cc:593:
>                         error:
>                         'getTargetThread' is not a member of 'SparcISA'
>                         In file included from
>                         build/SPARC_SE/cpu/inorder/cpu.hh:56,
>                                         from
>
> build/SPARC_SE/cpu/inorder/inorder_cpu_builder.cc:37:
>                         build/SPARC_SE/cpu/inorder/reg_dep_map.hh:49:
>                         error: 'TotalNumRegs' is
>                         not a member of 'SparcISA'
>                         In file included from
>
> build/SPARC_SE/cpu/inorder/resources/use_def.hh:44,
>                                         from
>
> build/SPARC_SE/cpu/inorder/resources/resource_list.hh:37,
>                                         from
>
> build/SPARC_SE/cpu/inorder/pipeline_traits.cc:34:
>                         build/SPARC_SE/cpu/inorder/reg_dep_map.hh:49:
>                         error: 'TotalNumRegs' is
>                         not a member of 'SparcISA'
>                         scons: ***
>
> [build/SPARC_SE/cpu/inorder/inorder_cpu_builder.fo
>                         <http://inorder_cpu_builder.fo>] Error 1
>                         scons: ***
>                         [build/SPARC_SE/cpu/inorder/inorder_dyn_inst.fo
>                         <http://inorder_dyn_inst.fo>] Error 1
>                         scons: ***
>                         [build/SPARC_SE/cpu/inorder/pipeline_traits.fo
>                         <http://pipeline_traits.fo>] Error 1
>                         In file included from
>                         build/SPARC_SE/cpu/inorder/cpu.hh:56,
>                                         from
>                         build/SPARC_SE/cpu/inorder/resource_pool.hh:45,
>                                         from
>                         build/SPARC_SE/cpu/inorder/pipeline_stage.cc:35:
>                         build/SPARC_SE/cpu/inorder/reg_dep_map.hh:49:
>                         error: 'TotalNumRegs' is
>                         not a member of 'SparcISA'
>                         scons: ***
>                         [build/SPARC_SE/cpu/inorder/pipeline_stage.fo
>                         <http://pipeline_stage.fo>] Error 1
>                         scons: building terminated because of errors.
>
>
>                         And, well, if I compile M5 without modifying
>                         scons, i get the following
>                         expected error:
>
>                         eberl...@bellatrix:~/UFSC/Workspaces/work_m5/m5$
>                         ./build/SPARC_SE/m5.fast configs/example/se.py
>                         -n 2 --inorder --caches
>                         --l2cache -c meu/hello
>                         M5 Simulator System
>
>                         Copyright (c) 2001-2008
>                         The Regents of The University of Michigan
>                         All Rights Reserved
>
>
>                         M5 compiled Jun 23 2010 12:50:36
>                         M5 revision edde97a6ea7c+ 7069+ default tip
>                         M5 started Jun 23 2010 12:56:44
>                         M5 executing on bellatrix
>                         command line: ./build/SPARC_SE/m5.fast
>                         configs/example/se.py -n 2
>                         --inorder --caches --l2cache -c meu/hello
>                         Traceback (most recent call last):
>                          File "<string>", line 1, in <module>
>                          File
>
> "/home/eberle18/UFSC/Workspaces/work_m5/m5/src/python/m5/main.py",
>                         line 359, in main
>                            exec filecode in scope
>                          File "configs/example/se.py", line 137, in
>                         <module>
>                            (CPUClass, test_mem_mode, FutureClass) =
>                         Simulation.setCPUClass(options)
>                          File
>
> "/home/eberle18/UFSC/Workspaces/work_m5/m5/configs/common/Simulation.py",
>                         line 53, in setCPUClass
>                            class TmpClass(InOrderCPU): pass
>                         NameError: global name 'InOrderCPU' is not
> defined
>
>                         --
>                         Eberle A. Rambo.
>
>
>
>                         On Wed, Jun 23, 2010 at 12:13 PM, soumyaroop
>                         roy <s...@cse.usf.edu
>                         <mailto:s...@cse.usf.edu>>wrote:
>
>                             Hello Eberle:
>
>                             Did you try inorder in the SPARC_SE mode
>                             yet? If yes, what errors did
>                             you get? If no, could you try simulating a
>                             program, say the
>                             /tests/quick/00.hello test, with the
>                             incorder cpu in SPARC_SE mode and
>                             tell us what errors you see?
>
>                             regards,
>                             Soumyaroop
>
>                             On Wed, Jun 23, 2010 at 9:50 AM, Eberle
>                             <rambo.u...@gmail.com
>                             <mailto:rambo.u...@gmail.com>> wrote:
>                             > Hi Soumyaroop,
>                             >
>                             > Do you, or someone else, can say what
>                             needs to be done to make
>                             InOrderCPU
>                             > work with SPARC?
>                             > What needs to be adapted, filenames...
>                             hints?
>                             >
>                             >
>                             >
>                             > Eberle
>                             >
>                             >
>                             > On Tue, Jun 22, 2010 at 11:34 AM,
>                             soumyaroop roy <s...@cse.usf.edu
>                             <mailto:s...@cse.usf.edu>>
>                             wrote:
>                             >>
>                             >> Hello Eberle:
>                             >>
>                             >> On Tue, Jun 22, 2010 at 10:04 AM,
>                             Eberle <rambo.u...@gmail.com
>                             <mailto:rambo.u...@gmail.com>>
>                             wrote:
>                             >> > I've read the thread about SPARC_FS
>                             and InOrderCPU, but I need to
>                             know
>                             >> > whether it works with SPARC_SE.
>                             >>
>                             >> Currently, SPARC ISA is not supported
>                             in InOrderCPU
>                             >>
>
> (http://m5sim.org/wiki/index.php/InOrder_ToDo_List).
>                             FS is currently
>                             >> not supported for any ISA.
>                             >>
>                             >> >
>                             >> >
>                             >> > And also: The TimingSimpleCPU is
>                             equivalent to InOrderCPU, in terms
>                             of
>                             >> > pipeline and memory access
> (reordering)?
>                             >>
>                             >> TimingSimpleCPU does not model a CPU
>                             pipeline.
>                             >>
>                             >> Please refer to the documentation of
>                             these CPUs here:
>                             >>
>                             >> TimingSimpleCPU:
>                             >> http://m5sim.org/wiki/index.php/SimpleCPU
>                             >>
>                             >> InOrderCpu:
>                             >> http://m5sim.org/wiki/index.php/InOrder
>                             >>
>                             >> >
>                             >> >
>                             >> >
>                             >> > --
>                             >> > Eberle A. Rambo.
>                             >>
>                             >> regards,
>                             >> Soumyaroop
>                             >>
>                             >> >
>                             >> >
>
> _______________________________________________
>                             >> > m5-users mailing list
>                             >> > m5-us...@m5sim.org
>                             <mailto:m5-us...@m5sim.org>
>                             >> >
>
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>                             >> >
>                             >>
>                             >>
>                             >>
>                             >> --
>                             >> Soumyaroop Roy
>                             >> Ph.D. Candidate
>                             >> Department of Computer Science and
>                             Engineering
>                             >> University of South Florida, Tampa
>                             >> http://www.csee.usf.edu/~sroy
>                             <http://www.csee.usf.edu/%7Esroy>
>                             <http://www.csee.usf.edu/%7Esroy>
>
>                             >>
>
> _______________________________________________
>                             >> m5-users mailing list
>                             >> m5-us...@m5sim.org
>                             <mailto:m5-us...@m5sim.org>
>                             >>
>
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>                             >
>                             >
>                             >
>
> _______________________________________________
>                             > m5-users mailing list
>                             > m5-us...@m5sim.org
>                             <mailto:m5-us...@m5sim.org>
>                             >
>
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>                             >
>
>
>
>                             --
>                             Soumyaroop Roy
>                             Ph.D. Candidate
>                             Department of Computer Science and
> Engineering
>                             University of South Florida, Tampa
>                             http://www.csee.usf.edu/~sroy
>                             <http://www.csee.usf.edu/%7Esroy>
>                             <http://www.csee.usf.edu/%7Esroy>
>
>
> _______________________________________________
>                             m5-users mailing list
>                             m5-us...@m5sim.org
> <mailto:m5-us...@m5sim.org>
>
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
>
>
>                         _______________________________________________
>                         m5-users mailing list
>                         m5-us...@m5sim.org <mailto:m5-us...@m5sim.org>
>
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
>
>
>
>                     --
>                     - Korey
>
>                     _______________________________________________
>                     m5-users mailing list
>                     m5-us...@m5sim.org <mailto:m5-us...@m5sim.org>
>                     http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
>
>
>                 _______________________________________________
>                 m5-dev mailing list
>                 m5-dev@m5sim.org <mailto:m5-dev@m5sim.org>
>                 http://m5sim.org/mailman/listinfo/m5-dev
>
>
>
>
>             --
>             - Korey
>
>
>
>         _______________________________________________
>         m5-dev mailing list
>         m5-dev@m5sim.org <mailto: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

_______________________________________________
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