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/[email protected]/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 <[email protected]> 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/[email protected]/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 <[email protected]> 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 <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Ok. I'll take a look at the microcode. >> > >> > That's the e-mail I've found: >> > http://www.mail-archive.com/[email protected]/msg03671.html >> > >> > -- >> > Eberle A. Rambo. >> > >> > >> > >> > On Wed, Jun 30, 2010 at 4:22 PM, Gabriel Michael Black >> > <[email protected] <mailto:[email protected]>> 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 <[email protected] >> > <mailto:[email protected]>>: >> > >> > 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 >> > <[email protected] <mailto:[email protected]>> 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 >> > <[email protected] <mailto:[email protected]>> wrote: >> > >> > oh, >> > if you do get into developing SPARC support for >> > the inorder model, let's >> > move the discussion to the [email protected] >> > <mailto:[email protected]> list which would be the >> > more >> > appropriate discussion board. >> > >> > >> > On Wed, Jun 23, 2010 at 11:58 AM, Eberle >> > <[email protected] >> > <mailto:[email protected]>> 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 <[email protected] >> > <mailto:[email protected]>>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 >> > <[email protected] >> > <mailto:[email protected]>> 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 <[email protected] >> > <mailto:[email protected]>> >> > wrote: >> > >> >> > >> Hello Eberle: >> > >> >> > >> On Tue, Jun 22, 2010 at 10:04 AM, >> > Eberle <[email protected] >> > <mailto:[email protected]>> >> > 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 >> > >> > [email protected] >> > <mailto:[email protected]> >> > >> > >> > >> > 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 >> > >> [email protected] >> > <mailto:[email protected]> >> > >> >> > >> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > > >> > > >> > > >> > >> > _______________________________________________ >> > > m5-users mailing list >> > > [email protected] >> > <mailto:[email protected]> >> > > >> > >> > 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 >> > [email protected] >> > <mailto:[email protected]> >> > >> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > >> > >> > >> > _______________________________________________ >> > m5-users mailing list >> > [email protected] <mailto:[email protected]> >> > >> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > >> > >> > >> > >> > -- >> > - Korey >> > >> > _______________________________________________ >> > m5-users mailing list >> > [email protected] <mailto:[email protected]> >> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > >> > >> > >> > _______________________________________________ >> > m5-dev mailing list >> > [email protected] <mailto:[email protected]> >> > http://m5sim.org/mailman/listinfo/m5-dev >> > >> > >> > >> > >> > -- >> > - Korey >> > >> > >> > >> > _______________________________________________ >> > m5-dev mailing list >> > [email protected] <mailto:[email protected]> >> > http://m5sim.org/mailman/listinfo/m5-dev >> > >> > >> > >> > ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > m5-dev mailing list >> > [email protected] >> > http://m5sim.org/mailman/listinfo/m5-dev >> > >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev > > > > -- > - Korey > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
