Modeling & Rendering Components & Friends
Any compiler will read & parse the source, convert it into an abstract natation (like the AST) and write the result back in a lower-language, or “binary format”. We have spend several posts on the parsing phase. This one focus on the last part: rendering the model into “generated C code”.
The goal is not to design “all & everything”. We pick some details, do some experiment (typically in Jupyter/IPython Notebook), and the lessons-learned are documented here.
Todo
Add (pseudo) namespaces-support, global/extern/static keyword and such (during generation)
Better design & describe the Pre/In/PostFixes (see XXXX)
Overview
Each component has 3 structures to fully describe the component; most are generated and/or filled by the compiler.
- CC_B_ComponentInterface
Describes the interface of a Component; more or less as by the Moat file
- CC_B_ComponentClass
A directory of the component implementation: which callables etc – including a “dispatch (v)table”
- CC_C_${CompName}
Data-structure for each instance for component ${CompName} – the place to store component-local-data
The first two are predefined (build-in) structures, that are filled (and named) by the compiler. (so global variables)
The last one is defined (
#typedef
) by the compiler.
This is handled byCC_Component
For each component that is coded in a Castle file, the CCastleCompiler will fill the structures CC_B_ComponentInterface
and a CC_B_ComponentClass
. Or more exact, it generates C-code to create a “global, read-only” variable (that will end up in de data-segment). This is part of the runtime.
Those variables get names as cc_CI_${CompName}
resp cc_C_${CompName}
(notice the lowercase prefix)
The CCastleCompiler will also define a new structure (as a typedef), called CC_C_${CompName}
(notice the uppercase prefix). They are not instantiated by the compiler. During executing of the Castle program, such a structure will be allocated for each component-instance. The size of the structure depend on the component. And as component do inherit, the structure-fiels of all super-components tripple down in the (top of) the new structure! This implies all CC_C_${CompName}
structures start by (“inherite from”) the baseComponent – which struct is called c:type:CC_B_Component – Notice the B in the name.
Note
The names of the structures & variables are based on the “handCompiled” version; they can/will change. But need to be aligned.
The variables (“instances”) start with cc_; in small-case.
The structures (“classes”) start in CC_; in capital.
Therefore, cc_C_${CompName} and CC_C_${CompName} are not the same.
The first is a instance of a CC_B_ComponentClass, the second is a generated type (for the same componentThis can be a bit confusing. Probably I will change the name(s) once …
Hint
Pre/In/Post-fixes
Components
_CI_ (infix) stands for Component-Interface,
_C_ (infix) stands for Component (implementation).
Probably beter abrivations will help
_B_ (infix) stands for Buildin
CC_ (prefix) is alike CCaste