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]> 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]>: > > > 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]> > 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] > http://m5sim.org/mailman/listinfo/m5-dev >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
