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
