On Tue, Apr 26, 2011 at 9:45 PM, Gabriel Michael Black < gbl...@eecs.umich.edu> wrote:
> People not working with the ISA parser can stop here. > Here I am :-). > Before I mentioned using @, and I have a patch that makes that change in > the parser and in all the ISA descs. It was less painful than you may > assume. > I haven't looked at your patches yet... is the main point of switching from . to @ to allow structure field accesses? > I don't think there's a good way to figure out whether operands are a > source and/or destination in a setup like this. In the past, I've tried to > come up with a scheme that would force gcc/C++ to figure it out for us, but > no matter how clever/depraved I allow my solutions to be, they still don't > work. It might be possible to use a fancy compiler system like LLVM to build > a new tool to do it, but that isn't a near term solution (although I > wouldn't rule it out entirely). One potentially interesting angle to pursue is gcc-xml... I don't know much about it except that, as the name implies, it generates an xml representation rather than machine code, which should be reasonably analyzable. I bet it's still hairy, but it might be the least hairy alternative. I expect the big problem with most of these approaches is that the final compilation context for most of the C snippets is not known at the time the code is parsed by the parser for operands etc. Thus there will be symbols that you can't disambiguate as types etc. because the proper include files haven't been included (which could be undecidable if the proper include files are also being generated in the same isa_parser run, so maybe they don't even exist yet at the point where you need them). This is why the ad hoc yet (as you say) surprisingly effective heuristics were used. Perhaps the heuristics could simply be extended to deal with structure field accesses... if the thing after the symbol is a ".", then you look past that to see if there's an equals sign or not, and behave appropriately. > Another solution might be to explicitly list source and destination > operands like inline assembly blocks. I definitely don't like this idea. One of the main motivations for the current implementation was the old SimpleScalar ISA definition macros, which required explicit listing of operands... and which as a result had subtle bugs that went undetected for years where particular dependencies weren't being enforced because someone left an operand out of the list. As you say, the current approach "works remarkably well most of the time", so while I'm all for improving it and addressing its shortcomings, I see no need to throw it out and replace it with something that's more manual effort, less concise, and more error prone. An extension that allows you to manually override what the parser finds. to deal with those cases where it's getting confused, would be fine though... basically sort of what you've been doing already, except that instead of "overriding" its heuristics by coming up with awkward code sequences that trick it into doing the right thing, you have a more blunt and effective path to do that. That's probably not as big a step forward as you want, but to me it's preferable to just switching to a fully manual explicit scheme. > Any ideas how we can get this to work better? This is a big stumbling block > for this sort of set up, and this will lead to operand types which can be > automatically composited from component values instead of having to have > hacks that, for instance, retrofit/filter code blobs to build double > precision floating point values from single precision ones behind the > scenes, or to merge control and condition code bits everywhere the whole > control register is needed, etc. I expect that last part to be important for > x86 to get the control flags dependency issues fixed in O3. > Would it help to have a way to explicitly declare compound operand types so that the parser can treat them intelligently? Maybe it could be as simple as declaring "operand foo has fields a, b, and c" and having that autmoatically turn into separate internal entries for foo, foo.a, foo.b, and foo.c in the operand-matching code, which are linked together so that the right inferences are made when any of them are found. Just a thought... Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
