Hi Eliot. The decoder, particularly the x86 decoder, is one of the most complex areas of gem5, and unfortunately there isn't any comprehensive documentation explaining how it works. I did put together this document a while ago ( https://docs.google.com/document/d/1quwxZOPb181jVWAh_7nX7E6uJM-7d9VDU9KxKkGmIrY/edit#heading=h.ogwesp50kyg) which describes how the decoders in gem5 work in general, although I haven't looked at it in a while and I don't remember exactly what's in there.
As far as the tags which describe where an instructions operands come from, the most important part of the implementation is specialize.py, I think. It may have a slightly different name. That file implements the code which parses the tags and prepares operands for the instruction, whether they're registers, address components, etc. The tags themselves are based on the operand description shorthand used in the AMD manuals in their instruction reference, where generally one letter describes where the operand comes from, and another letter describes the operand size. The actual size will usually depend on other factors like the default operand size, the mode you're in, etc, so the letter for the size really describes a pattern of sizing than a particular size. The microops themselves are more like what you would see in other ISAs since they're the actual instructions which get executed by the CPUs. The one additional difference is that they plug into the microcode assembler so that they can be used in macroops. That's done with a python class which is instantiated using the operands from the microcode, so, roughtly speaking: add r1, r2, r3, operand_size=2 could map to: Add(r1, r2, r3, operand_size=2) where Add is the python class which represents the microop. The variables r1, r2, and r3 would be defined elsewhere as strings which will eventually get pasted into the C++ and would be the index for r1, r2, r3, etc. Gabe On Mon, May 24, 2021 at 11:52 AM Eliot Moss via gem5-users < gem5-users@gem5.org> wrote: > Hi, all -- > > I've been using an older version of Gem5 for some time (inherited from an > existing project) for some ARM simulations, but now am moving to do > something > new on x86. > > The particular task where I'd like some guidance is this: > > I want to add an instruction that will send a command to the cache(s). It > does not need to mention a specific address, but may send some data. I was > thinking of encoding it the same way as clwb, but using the currently > disallowed 11 (i.e., 3) combination of the mod/rm bits. This generally > indicates a register as opposed to a memory operand. I think I have found > more or less where to do this in the decoder, but if someone would respond > about that, it would be helpful. > > Then there is the question of the other steps of adding an instruction, > which > starts getting more mysterious (e.g., what does Iz, for example mean, and > is > it what I want if I want this new instruction to have a register operand?). > > It will seem I'll need to add a micro-op as well. I can follow the clwb > model > for that, except that this special thing will probably use some new flag in > its request/packet that will head toward the cache (and of course I will be > extending the cache to notice and handle that for the new thing I'm > devising). > > An overall sketch of how to accomplish this successfully and going with the > flow of the design would be great. If there are specific pieces of > documentation I should be looking at it, pointers to them would also be > gratefully accepted. > > Regards, and thanks in advance - Eliot Moss > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
