| Revisión | ffe72e64dc77f86acb6a1a9690b5fb2b154d60d9 (tree) |
|---|---|
| Tiempo | 2022-12-22 22:20:13 |
| Autor | Albert Mietus < albert AT mietus DOT nl > |
| Commiter | Albert Mietus < albert AT mietus DOT nl > |
refactored Components_and_Friends; now it's RST
| @@ -2,59 +2,73 @@ | ||
| 2 | 2 | Modeling & Rendering Components & Friends |
| 3 | 3 | ========================================= |
| 4 | 4 | |
| 5 | -.. hint:: Sources | |
| 5 | +.. post:: | |
| 6 | + :category: Castle, DesignStudy | |
| 7 | + :tags: DRAFT | |
| 6 | 8 | |
| 7 | - * ModelMore.ipynb, which is baed on | |
| 9 | + Any compiler will read & parse the source, convert it into an abstract natation (like the AST) and write the result | |
| 10 | + back in a lower-language, or “binary format”. We have spend several posts on the parsing phase. This one focus on | |
| 11 | + the last part: *rendering* the model into “generated C code”. | |
| 12 | + | |
| 13 | + The goal is not to design “all & everything”. We pick some details, do some experiment (typically in Jupyter/IPython | |
| 14 | + Notebook), and the lessons-learned are documented here. | |
| 15 | + | |
| 16 | + | |
| 17 | +.. IPython Sources | |
| 18 | + | |
| 19 | + * ModelMore.ipynb, which is based on | |
| 8 | 20 | * Model-GCD.ipynb |
| 9 | 21 | |
| 10 | - Currently (Dec 12, 2022), this file (`CCastle2/IPython/Components.py` is most updated one | |
| 22 | + They have become outdated by this (draft) post | |
| 11 | 23 | |
| 12 | 24 | .. todo:: |
| 13 | - Spilt the Modeling & Rendering parts; by using delegating to a ${Any}Rendering subclasses of ${Any} | |
| 14 | 25 | |
| 15 | -.. caution:: The text below needs to converted from MD to RST | |
| 16 | - | |
| 26 | + * Spilt the Modeling & Rendering parts; by using delegating to a ${Any}Rendering subclasses of ${Any} | |
| 27 | + * Add (pseudo) namespaces-support, global/extern/static keyword and such (during generation) | |
| 28 | + | |
| 29 | + | |
| 17 | 30 | Overview |
| 18 | 31 | ========= |
| 19 | 32 | |
| 20 | 33 | Each component has 3 structures to fully describe the component; most are generated and/or filled by the compiler. |
| 21 | 34 | |
| 22 | 35 | **CC_B_ComponentInterface** |
| 23 | - Describes the interface (as by the Moat file) | |
| 36 | + Describes the interface of a Component; more or less as by the Moat file | |
| 24 | 37 | **CC_B_ComponentClass** |
| 25 | - Describe a component (as class) (as by the Castle-file) | |
| 38 | + A *directory* of the component implementation: which callables etc -- including a “dispatch (v)table” | |
| 26 | 39 | *CC_C_${CompName}* |
| 27 | - Characterises each instance for component *${CompName}*. | |
| 28 | - | |
| 29 | - This is handled by :class:`CC_Component` | |
| 30 | - | |
| 31 | -The first two are predefined (build-in) structures that are filled (and named) by the compiler. | |
| 32 | -The last one is defined (```#typedef```) by the compiler. | |
| 33 | - | |
| 34 | -For each component that is *coded* in a Castle file, the structures `CC_B_ComponentInterface` and a | |
| 35 | -`CC_B_ComponentClass` are filled (read: a variable of that type is instancianted); they get the name | |
| 36 | -cc_CI_\\${*CompName*}** resp **cc_C_${*CompName*}**. | |
| 37 | -<br/> | |
| 38 | -And, a new structure `CC_C_${CompName}` is defined (but not instanciated); the size of that struct depend on the component. As components do inherite, 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 CC_**B**_Component | |
| 39 | - | |
| 40 | -#### <span style="color:blue">Notes</span> | |
| 40 | + Data-structure for each instance for component *${CompName}* -- the place to store component-local-data | |
| 41 | 41 | |
| 42 | -* The names of the structures & variables are based on the *"handCompiled"* version; they can/will change. But need to be alligned | |
| 43 | -* The variables ("instances") start with **cc_**; in small-case | |
| 44 | -* The structures ("classes") start in **CC_**; in captial | |
| 45 | -* 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 component | |
| 46 | -* This can be a bit confusing. Probally I will change the name(s) | |
| 42 | +* The first two are predefined (build-in) structures, that are filled (and named) by the compiler. (so global variables) | |
| 43 | +* The last one is defined (``#typedef``) by the compiler. | |
| 44 | + |BR| | |
| 45 | + This is handled by :class:`CC_Component` | |
| 47 | 46 | |
| 48 | -#### Prefix/Infix/Suffix | |
| 49 | -* Components | |
| 50 | - - <span style="background: lightblue;">\_CI\_</span> (infix) | |
| 51 | - stands for **C**omponent-**I**nterface, | |
| 52 | - - <span style="background: lightblue;">\_C\_</span> (infix) | |
| 53 | - stands for **C**omponent (implementation). | |
| 54 | - - <span style="color: purple;">Probally beter abrivations will help</span> | |
| 55 | -* The infix <span style="background: lightblue;">\_B\_</span> | |
| 56 | - stands for **B**uildin | |
| 57 | -* The prefix <span style="background: lightblue;">CC\_</span> | |
| 58 | - is alike CCaste | |
| 47 | +For each component that is *coded* in a Castle file, the CCastleCompiler will fill the structures :c:struct:`CC_B_ComponentInterface` and a :c:struct:`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. | |
| 48 | +|BR| | |
| 49 | +Those variables get names as ``cc_CI_${CompName}`` resp ``cc_C_${CompName}`` (notice the lowercase prefix) | |
| 59 | 50 | |
| 60 | -Below we show the rendering of **CC_C_${CompName}** first. And them the other two; However, the need details al **`port`** & **`protocols`**; so the are defined too. | |
| 51 | +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. | |
| 52 | + | |
| 53 | +.. Note:: | |
| 54 | + | |
| 55 | + * The names of the structures & variables are based on the *"handCompiled"* version; they can/will change. But need to be aligned. | |
| 56 | + * The variables ("instances") start with **cc_**; in small-case. | |
| 57 | + * The structures ("classes") start in **CC_**; in capital. | |
| 58 | + * Therefore, *cc_C_${CompName}* and *CC_C_${CompName}* are not the same. | |
| 59 | + |BR| | |
| 60 | + The first is a instance of a CC_B_ComponentClass, the second is a generated type (for the same component | |
| 61 | + * This can be a bit confusing. Probably I will change the name(s) once ... | |
| 62 | + | |
| 63 | +.. hint:: Pre/In/Post-fixes | |
| 64 | + | |
| 65 | + * Components | |
| 66 | + | |
| 67 | + - **_CI_** (infix) stands for **C**\omponent-**I**\nterface, | |
| 68 | + - **_C_** (infix) stands for **C**\omponent (implementation). | |
| 69 | + - *Probably beter abrivations will help* | |
| 70 | + | |
| 71 | + * **_B_** (infix) stands for **B**\uildin | |
| 72 | + * **CC_** (prefix) is alike CCaste | |
| 73 | + | |
| 74 | + |
Fork
CCastle/3.Design/B.Workshop/C.py/Components_and_Friends.rst