Quoting nathan binkert <n...@binkert.org>:
A mechanism where I can say binary foo needs file bar, and then when I tell
it to build foo it build's it with bar, and bar doesn't get mixed in to
other things. I think you're new widget that was like mercurial patch guards
would help with that, right? You could have a guard for each extra target.
Ah, I see. I personally wouldn't use any of that. Don't use Source
or PySource or that sort of thing. Just set up normal looking
SConscript files with their own targets and such. The
Source/PySource/etc. stuff is really about building the m5 binary and
dealing with all of the variations that we have.
Ok.
I'm not sure how SLICC is structured, but it might be hard to get out file
information without running the whole description, depending on how the
multi-file output thing is implemented.
In SLICC, we parse the entire file using the ply grammar and generate
the AST in both phases. In one phase, you walk the AST simply to
figure out which files will be generated. In the other, you actually
do the generation. I'm suggesting that you do that as well, the files
aren't that long and I bet that parsing the ISA desc files and
generating the AST takes a second or so.
That doesn't really fit with how the ISA files work. They get broken
into an AST, but that gets consumed as it goes, and it has a lot of
anonymous python in it that just gets executed somehow. I want to move
more into the python, so the AST will be less and less useful. I'm not
sure whether the new support will be with explicit language support or
part of the embedded python. I would prefer the later, but if it's
harder to use that way language support may be best. Ultimately I want
to make the ISA stuff a part of regular python scripts instead of the
python being embedded in the ISA stuff, so in the longer term it will
probably be best to have that mechanism in regular python.
Gabe
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
