The way it all works is a little magical, but you can add the string "IsCall" to the InstObjParams constructor's opt_args parameter which defaults to an empty list. Because it has "Is" at the front, the parser assumes it's a static inst flag and sets things up appropriately. I'm pretty sure I've taken advantage of that in the past, and if you look at isa_parser.py you'll see the InstObjParams class definition which is what I'm looking at to remind myself with right now. Assuming everything lines up like I think it will, this should be a pretty easy change to make.
Gabe On 02/15/11 12:39, Andrew Lukefahr wrote: > Hi, > > What's the best way to implement StaticInst::isCall() for the ARM > ISA. It sounds like the function call is BL (branch with link), so > that should just require some modifications to the ARM isa files. > > Basically, it looks like I want to add something like > > if (link): flags =''' flags[IsCall] = true; ''' > else flag = "" > > in ./arch/arm/isa/insts/branch.isa. But then I'm not sure where to go > from there. Should I modify InstObjParams to include my new "flags" > parameter? But I'm not sure where InstObjParams is defined or how > much trouble it would be to modify it. What other files will I need to > modify? Or is there a simpler way altogether? > > Thanks > > Andrew Lukefahr > [email protected] <mailto:[email protected]> > > Open Source, Open Minds > > > On Thu, Feb 10, 2011 at 12:52 PM, Ali Saidi <[email protected] > <mailto:[email protected]>> wrote: > > You're right that many instructions can just write to r15 and > cause a branch, however that is generally not done and discouraged. > > Ali > > > > On Thu, 10 Feb 2011 12:32:37 -0500, Andrew Lukefahr > <[email protected] <mailto:[email protected]>> wrote: > >> Hi, >> >> Lets back up a bit. I'm trying to find hot loops in the program >> that might include function calls. Any time I find a PC < the >> last PC, I'm calling that a back edge. So I'm trying to >> distinguish a back edge of a function call/return from the back >> edge of a loop. My original plan was to use exclude >> unconditional branches (which are most likely function >> calls/returns) from being back-edges. >> >> However, having done a little more research, it appears ARM turns >> that on its head. Correct me if I'm wrong, but it uses r15 as >> the PC register, and the programmer is allowed to directly access >> that on most instructions. For example to return from an function >> call, instead of the traditional "ret" (an unconditional >> branch), the programmer (or compiler) can use a move or a load >> from memory (or others?) to set r15. Neither of these are even >> branches, let alone traditional "unconditional" branches. >> >> So now I'm not sure how much "isCondCtrl" and "isUncondCtrl" are >> going to help me. I'm trying to find a way to come up with a way >> of distinguishing function calls and returns from loops using >> just StaticInst, without having to look at ARM specific >> instructions. >> >> Thanks >> >> >> Andrew Lukefahr >> [email protected] <mailto:[email protected]> >> >> Open Source, Open Minds >> >> >> On Wed, Feb 9, 2011 at 11:48 PM, Ali Saidi <[email protected] >> <mailto:[email protected]>> wrote: >> >> As Gabe said, pretty much every instruction in ARM is >> conditional so by that definition there isn't such thing as >> an unconditional branch. When the condition is always or >> unconditional it becomes closer to an unconditional branch >> and perhaps we should set the conditional/unconditional flags >> on the branches based on that, but as you noticed we don't. >> Feel free to give it a try. You should be able to add it to >> the branches constructor around the lines that say if >> (!(condCode == COND_AL || condCode == COND_UC)) { >> >> Ali >> >> On Feb 8, 2011, at 12:37 PM, Gabriel Michael Black wrote: >> >> > Without actually looking at the code, I'm pretty sure those >> flags just aren't being set when those instructions are >> defined. That would be done in the ISA description files in >> the arch/arm/isa directory. I don't think instructions that >> set R15 (the PC register) are currently being marked as >> control instructions. Also whether an instruction is >> conditional or not is a fuzzy concept in ARM. They can all be >> conditional because of predicated execution, with a few >> exceptions, but often the condition is "always" which is >> effectively unconditional. The current ARM maintainers (Ali >> and others) might be better able to help you. I might >> implement something too, but I can't test changes as well as >> they can and might not have time for a while. >> > >> > Gabe >> > >> > Quoting Andrew Lukefahr <[email protected] >> <mailto:[email protected]>>: >> > >> >> Hi, >> >> >> >> I'm trying to determine when a StaticInst is a conditional >> vs unconditional >> >> branch using the ARM ISA. The StaticInstBase class has a >> isControl() >> >> function that seems to work, but the isCondCtrl() and >> isUncondCtrl() do >> >> not. Further grep'ing revealed that in my >> build/ARM_SE/arch/arm/decoder.cc >> >> file, I have lots of "flags[IsControl]=true;" statements, >> but none for the >> >> CondCtrl and UncondCtrl. >> >> >> >> So, >> >> 1) Is there a better way to decide if an inst is a >> conditional vs >> >> unconditional branch? >> >> 2) If not, where would I add cond/uncond flags to the ISA? >> >> >> >> Thanks >> >> >> >> Andrew Lukefahr >> >> [email protected] <mailto:[email protected]> >> >> >> >> Open Source, Open Minds >> >> >> > >> > >> > _______________________________________________ >> > m5-users mailing list >> > [email protected] <mailto:[email protected]> >> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > >> >> _______________________________________________ >> m5-users mailing list >> [email protected] <mailto:[email protected]> >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> >> > > > > _______________________________________________ > m5-users mailing list > [email protected] <mailto:[email protected]> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
