src/openpower/decoder/helpers.py currently has a lot of functions here and there. Putting aside massive global scope pollution, it also introduces another problem: it's completely unusable when some of the functions must be updated so that they take an advantage of XLEN variable. Since XLEN is not part of global scope, it's impossible for instructions to make use of XLEN.
The solution is to distribute everything as part of a class which is XLEN-aware. Once functions are converted into methods, they can access class internals. The created class is supposed to be inherited by ISACaller.
The works include the following steps:
* create a stub class with methods which call the routines from the global scope
* teach decoder/pseudo/parser.py to deal with these methods instead of global routines
* once parser calls all routines from the class, move all the gory implementation details from global scope into the methods
the basis of this one is as dmitry says, XLEN needs to be
available to all helpers, and we are not going to
modify the functions to add it as an argument.
so the only other way is to drop all helper routines
(including those compiled by pyfnwriter) into a class,
which ISACaller happens to inherit from.
that in turn means that a list of all helper
routines needs to be created....
the helper.py class actually imported and introspection
for pyfnwriter functions that technique will
not work because the routines themselves are
in fact autogenerated *by* the parser, so will
have to be handled differently.
this all unfortunately needs to be done in "one hit" so sigh
a branch is, reluctantly, probably the most sensible option.
The class with the redirection logic is submitted. Functions will migrate from the global scope on demand to minimize changes at this stage.
looks great dmitry, pyfnwriter should be checked, then i think
I thought about these for a while, they have one problem. We run pywriter and pyfnwriter as separate stages; one doesn't know of another. We can for sure collect names which we met so far in pyfnwriter stage; but these are unavailable outside of pyfnwriter, so pywriter have no idea which names should be checked w.r.t. "self." prefix addition before the call. Any ideas?
The simpler option would be to add "self." prefix unconditionally and distribute everything as part of our class; I feel, however, that this might bring other problems in the future. What's your take on this?
If the first option is good, I have a patch which already takes care of all `def` sections for pywriter. Perhaps `pyfnwriter` could expose these as part of build or maybe via special option, and `pywriter` could re-use the list.
pyfnwriter should be generating "self." in front of
everything, yes. however, annoyingly, this looks like
either a 2 pass situation or just having an explicit
BCD_TO_DPD etc temporarily need to be added to the list