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 by CC_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 component

  • This 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