Theoretically the current header-based backend for C may be reused for C++. The only thing that should be improved is wrapping the inconvenient bitfield-access macros with elegant C++ methods.
However, when connecting the AGWB-described control-tree to a C++ software it is likely that the end user wants to avoid recompilation of the software whenever the hardware is modified. Therefore a representation capable of resolving the addresses at runtime is needed.
My first idea is to imitate the behaviour or the current Python backend.
The AGWB output should provide the set of classes reflecting the addressable objects:
Registers and registers with bitfields
Vectors of registers
Blocks (which may contain registers and/or vectors of registers)
Vectors of blocks
The convenient feature of the Python backend is that the hierarchy of the control-tree is fully reflected by the hierarchy of objects.
Of course with run-time resolved description we can't dereference the objects like in Python, by including the names of objects in the code:
In case if certain node in the control-tree hierarchy is supposed to be often used for looking up its children, we should be able to keep a reference to it.
For run-time dereferencing we should pass the above path as the argument to the e.g. resolve function of the addressable object from which we start looking for a child.
The resolve function takes two arguments: offset and path.
For each node the following information is stored:
Information whether it is a vector objects (blocks or registers)
Offset (for non-vectors - its offset from the base address of its parrent, for vectors - the offset of the first element of the base address of the parrent)
Size of the element (only for vectors)
number of elements (only for vectors)
The resolve function works as follows
If the path starts with "[", it is verified that the current node is a vector (if not, an exception is thrown). Then the number of the selected element is extracted (until "]") and hence its offset is calculated .
The path is parsed using "." and "[" as a separator.
The extracted token is used as a identifier of a child.
The resolve method of the child is called, until we reach the end of path (or we reach the register with bitfields, because bitfields must be treated in a special way).
An important issue is how we can efficiently handle dynamic indexes when accessing an object.
At the moment the only way to do that is to get the reference to the vector object (blockA.blocksB in the above example), then use its [] method to get the reference to the selected element, and repeat the above at each index.
Another possibility is to use the approach implemented in the Forth backend. We should:
provide the vector of indices as the third argument of the resolve function,
or add two additional arguments at the end: the pointer to the list of indices and the number of indices.
Whenever "[ index ]" is found in the path, we consume one index and locate the appropriate element in the vector, and pass the rest of the list of indices to the resolve function of that element.
This is the first description of the problem and possible solution.
Any comments and suggestions are appreciated.
Theoretically the current header-based backend for C may be reused for C++. The only thing that should be improved is wrapping the inconvenient bitfield-access macros with elegant C++ methods.
However, when connecting the AGWB-described control-tree to a C++ software it is likely that the end user wants to avoid recompilation of the software whenever the hardware is modified. Therefore a representation capable of resolving the addresses at runtime is needed.
My first idea is to imitate the behaviour or the current Python backend. The AGWB output should provide the set of classes reflecting the addressable objects:
The convenient feature of the Python backend is that the hierarchy of the control-tree is fully reflected by the hierarchy of objects. Of course with run-time resolved description we can't dereference the objects like in Python, by including the names of objects in the code:
blockA.blocksB[nrb].blocksC[nrc].regsA[nrA].bitfieldAIn case if certain node in the control-tree hierarchy is supposed to be often used for looking up its children, we should be able to keep a reference to it. For run-time dereferencing we should pass the above path as the argument to the e.g.
resolvefunction of the addressable object from which we start looking for a child. Theresolvefunction takes two arguments:offsetandpath.resolvefunction works as followsresolvemethod of the child is called, until we reach the end of path (or we reach the register with bitfields, because bitfields must be treated in a special way).An important issue is how we can efficiently handle dynamic indexes when accessing an object. At the moment the only way to do that is to get the reference to the vector object (
blockA.blocksBin the above example), then use its[]method to get the reference to the selected element, and repeat the above at each index.Another possibility is to use the approach implemented in the Forth backend. We should:
resolvefunction,Whenever "[ index ]" is found in the path, we consume one index and locate the appropriate element in the vector, and pass the rest of the list of indices to the
resolvefunction of that element.This is the first description of the problem and possible solution. Any comments and suggestions are appreciated.