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 Steve Reinhardt wrote: > > > On Wed, Sep 17, 2008 at 12:14 AM, Gabe Black <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > I think we're talking about mostly the same thing. The ROM bit > would be > global, but in the same sense that the PC is global. > > > OK, I'll buy that... it's global in that there's one per thread > context, but non-global in the sense that that one value really only > affects fetch and nothing else. When you were talking about a global > mode bit before I was thinking of things that really do have more > global effect like privilege mode. > > > It carries from uop > to uop passively as they flow through until you hit a point where > you're > moving to a new macroop or into the ROM. It would be associated with a > given uop which is already associated with a given PC and uPC, so > if you > had to go back to uop X which came from the ROM, it'd go to the right > place. It'd be basically like a third, single bit PC. I'd like > something > conceptually similar to NPC to change it as well. Maybe there would be > two bools, fromRom and nextFromRom? Those names aren't that great, but > you get the idea. > > > Yea, that seems reasonable to me. I guess you can argue that with x86 > the low-order PC bit is already in use... > > Steve > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
