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 > 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
