I have the microbranches ready to go, so now we need to figure out the details of how you switch to and from the ROM. I think something like fromRom and nextFromRom would work, although the names aren't that great. If anyone has a suggestion for a different mechanism or better names, please let me know.
Gabe Gabe Black wrote: > There is no limit on what you can do combinationally. The problem with > making every branch go to the ROM, or really the reason that doesn't > actually buy us anything, is that the micropc changes all the time in > the middle. If you made micropcs only relevant in the ROM, then you'd > need the combinational microops to be fed in a strict sequence out of > the macroop. If the decoder keeps track of that, it needs a way to tell > the macroop what's next and we've reintroduced a micropc. If the macroop > itself keeps track of that, it's not a static StaticInst anymore. Then > at some point you'd still need to switch the state from combinational to > ROM based when you'd reached a branch, so you'd still need to mark that > microop specially and you'd still need to keep some state and a > transition mechanism in the CPU. > > You're right about making everything combinational. I had planned on > supporting a ROM from the beginning and built support into the > microassembler for it, but in the interests of getting running microcode > I just made everything combinational to get it working. I will > definitely move the more complex instructions into the ROM, hopefully > making all branches into the ROM so that there's only one version of > branch. That would just simplify the implementation of my microops, > though, and wouldn't really do anything at the level of the decoder or CPU. > > Gabe > > Steve Reinhardt wrote: > >> OK, I see... the combination of only branching to the start of a quad >> and not being able to generate more than one quad combinationally >> makes branching in a combinational sequence meaningless on the real >> machine. >> >> Is there an upper bound on the number of microops you can generate in >> m5 through the "combinational" path? Even though it's more >> artificial, would it make sense to keep the restriction that if you >> need a microbranch you have to go to the ROM? >> >> At an even higher level, my impression is that you were making >> everything "combinational" because until you hit interrupt handling >> there was no absolute need for a microcode ROM... but now that you >> have one, should you revisit that, and start putting the more complex >> instruction sequences in the ROM as well? Would that allow you to >> simplify some of the sequencing logic? >> >> Steve >> >> On Thu, Sep 18, 2008 at 10:36 AM, <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> There is conceptually no upper bound, but really it's because you >> simply can't >> branch withing the number of microops generated by the >> combinational decoder. >> It's generating what amounts to an atomic VLIW vector of >> operations where >> control happens between entire vectors. Only one comes out of the >> combinational >> decoder, so it's like you get one instruction at that point. >> Either that one >> instruction does the trick, or you need to go to the ROM where a >> micropc >> conceptually exists. >> >> Gabe >> >> Quoting Steve Reinhardt <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: >> >> > I see...the only reason I saw to switch to relative branches is >> that it >> > avoids the need to distinguish between ROM and non-ROM targets. >> I guess the >> > argument for their approach is that if your microcode flow is >> complex enough >> > to require a branch then it's probably complex enough to need to >> come out of >> > ROM anyway. I'm guessing the difference with what you're doing >> is that >> > there's no hard upper bound on the number of microops you can >> generate via >> > the "combinational" decoder; is that true? >> > >> > Steve >> > >> > On Thu, Sep 18, 2008 at 12:52 AM, Gabe Black >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >> > >> > > This email is a minor informational update on the >> > > microcode/micropc/branching/ROM stuff. >> > > >> > > I started working on making the microbranches relative, but I >> had a hard >> > > time getting it to work because of how the microcode listing is >> > > processed and needing to know the current micropc in order to >> compute >> > > the argument for the branch microop. I went to check the >> patent to just >> > > to make sure I was thinking about things the right way, and it >> turns out >> > > I was wrong about two things. First, the branches are absolute >> and not >> > > relative. This makes a lot of sense because you eliminate the >> need for >> > > an adder to computer your target, and also one big win of relative >> > > branches, relocatable code, is moot in a ROM like this. >> Second, branches >> > > are not register operations. They come in one or two parts and are >> > > centered around generating quads of operations from the ROM on >> each >> > > read. On the end of a quad, there's a field called OpSeq which >> directs >> > > you to the next quad to fetch and is similar to what I'd call >> a branch. >> > > It has a 12 bit field which encodes it's target, and since it >> deals with >> > > a quad of microops, I'd say it's 14 effective bits. If you want a >> > > conditional branch, one of the operations in the quad says >> what the >> > > condition is and what the fall through address is, and there >> are 17 bits >> > > for that. Since that's all tied to having quads and that's a >> little to >> > > specific to a particular implementation for M5, I think, it >> seems more >> > > appropriate to have a conditional branch microop that just does >> > > everything at once. What I did before was make the branch >> instruction a >> > > register operation which only supports 8 bits of immediate >> because that >> > > made it easy to make it conditional. What I should really do >> is move the >> > > branch instruction to the right category and extend the >> immediate field >> > > to 16 bits, a handy number which approximates what's in the >> patent. >> > > >> > > Also, as far as different address spaces for the ROM and the >> macroop, >> > > the patent handles that by making -all- branches go to the >> ROM, and by >> > > making the unit of execution a quad. That way, if you're not >> finished >> > > when you execute the one and only combinational quad >> associated with an >> > > instruction (which effectively has no micropc), you always go to >> > > someplace in the ROM with a branch. This again doesn't work for M5 >> > > because we're not architected around quads and all microops >> have a micropc. >> > > >> > > Gabe >> > > >> > >> >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
