Thanks for the update Gabe.
I actually dont think getting SPARC to work would be too hard given what you
describe and assuming whoever is doing it has a good knowledge of the M5
infrastructure.
In terms of register index flattening, i suppose you have to flatten an
index before you use it, so that's probably can be added where we start
using the register indexes (use_def/execution.cc).
I'm not sure how that affects the register file dependencies and forwarding
so maybe slight changes need to be made there as well.
For the microcode portion, we could just define an applicable resource for
that ("MicroCodeUnit" or just modify the "DecodeUnit") and then that could
generate the requisitie microcode ops.
(Coincidentally, I had planned to get some register window stuff for some
other work but that's probably way too far off for anybody to depend on.)
Lastly, I wouldnt worry too much about the cross-thread register stuff, if
it's not applicable for a particular ISA, a placeholder and a panic is
probably in order there (and probably what ALPHA does).
On Wed, Jun 23, 2010 at 2:20 PM, Gabe Black <gbl...@eecs.umich.edu> wrote:
> SPARC works using (mostly) normal mechanisms, so for register windowing
> all you'd need is to support register flattening which ideally should be
> there for all ISAs. The process startup code puts fill and spill
> handlers in memory which work using non-microcoded instructions as far
> as I remember. SPARC does have a few microcoded instructions, assuming
> that hasn't changed since I worked on it last, so to fully work InOrder
> would need to minimally support microcode. Only x86 uses microcode
> internal control flow as far as I know, and not supporting that would
> make some things a little easier. The register file size is a parameter
> provided by the ISA, so again to work correctly InOrder just needs to
> use that parameter when allocating its register file. The compiler
> errors in that other email are from some components of MIPS and I guess
> now also Alpha which InOrder assumes are there. I'm hopeful at least
> some of these can be folded into other existing mechanisms
> (TotalNumRegs), but I haven't looked at that very closely and it may not
> be possible or may be really cumbersome (maybe the cross thread register
> stuff).
>
> Gabe
>
> Korey Sewell wrote:
> > Primarily,
> > you need to figure out how to support the register windows in SPARC in
> > the Inorder model.
> >
> > Now, Gabe I believe has got SPARC working for the simplecpu models so
> > the 1st step is figuring the ins/outs of how the register
> > names/indexes are interpreted for different windows for the simple model.
> >
> > Once you get that straightened out, you would need to instantiate a
> > register file large enough to support register windows and then to
> > update the "use_def.cc" and "execution_unit.cc" files to read/write
> > registers from the correct window.
> >
> > Also register spill / fill code I'm not sure if there are micro-ops or
> > actual ISA instructions that trigger that so that functionality needs
> > to be added to the pipeline as well.
> >
> >
> > 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-users@m5sim.org <mailto:m5-users@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-users@m5sim.org <mailto:m5-users@m5sim.org>
> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
> >
> >
> >
> > _______________________________________________
> > m5-users mailing list
> > m5-users@m5sim.org <mailto:m5-users@m5sim.org>
> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
> >
> >
> >
> >
> > --
> > - Korey
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > m5-users mailing list
> > m5-users@m5sim.org
> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
> _______________________________________________
> m5-users mailing list
> m5-users@m5sim.org
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
--
- Korey
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
