What is the goal of theCompiler ?
Introduction
The main goal of theCompiler is to support Meta-Programming.
meta-programming
The Meta-Programming is a language-design to increase the productivity of a senior programmer to 10.000 - 100.000 new or updated lines of code, documentation or configuration per day.
- managed-object-support
- extend the c-programming-language with a class-object to support the object-life-cycle.
- documentation-support
- create a documentation-reference of the new api using the doxygen-tool together with generated input and configuration files.
- test-support
- create a test-environment used to verify the new api.
project root
The
root of the
meta-programming is the
libmsgque-application-server, an infrastructure to integrate multiple
package-items into a single application.
- managed-object-support
- is using the integration-feature of the libmsgque-application-server to support the thread-safty and the object-life-cycle.
- target-language-support
- is using the network-stack of the libmsgque-application-server to provide the rpc-feature, cross-plattform and network-work-distribution support.
details
managed-object-support
The managed-object-support is a design method to extend the c-source-code by adding missing but common useable features.
The c-source-code-extension is designed as an addon to the c-syntax using:
- a code-generator to add new code into existing code to extend and standardize usability
- a design-interface to integrate different parts of the software
- a build-system to create a shared library ready to link into the target.
The link of c-source-code and the c-source-code-extension is called the c-meta-code.
The new features added by the c-source-code-extension are:
- thread management feature
- add a runtime defined as global thread-local-struct to every thread/process
- memory mangement feature
- thread-local-storage support
- runtime-local-storage support
- class based object feature
- object-life-cycle support
- object-slot support
- compile-time-type-cast support
- run-time-type-cast support
- support of pointer-type and reference-type operation
- logging and debugging feature
POINTER or REFERENCE
target-language-support
The c-meta-code used to integrate an existing c-library into a Target-Programming-Language (TPL).
The c-meta-code uses the following tools and input-files to achieve this goal:
- An already available api-header file defining the API as c-header-file.
- Usually the original api-header-file from the source distribution.
- A frontend-tool to transform the already available api-header and api-docu into a standardized-COMPILER-input-file-format
- A extension-tool to extend the c-header-file-syntax called: __parser__
- Add a new library defition syntax to the already available c-library-definition without break the c-compiler compatibility.
- Add a new attribute to an already existing c-code-definition.
- A class-tool to create a managed-class-object as C-code
- A meta-compiler to transform the standardized-COMPILER-input-file-format into the standardized-META-input-file-format (meta-code)
- The standardized-META-input-file-format is the input-file for all other backend-tools
- The missing-compiler to create the missing C-source-code and C-header-definition (later more)
- Multiple backend-tools to transform the meta-code into different Target-Programming-Language (TPL) targets:
- A code-target to create the target-module-code from the meta-code
- A module-target to create a target-module from the target-module-code
- A documentation-target to create the target-module-reference from the meta-code
- A rpc-target to create the rpc-server from the target-module and the meta-code
- ALC-compiler
- The bundel of the frontend, meta-compiler and backend is called: ALC-compiler.
- ALC
- ALS is the synnonyme for All-Language-Compiler because the ALS is able to generate the source-code for a target-programming-language and also configuration-file for a user-tool.
Workflow of the target-language-support
description | tool | input | generate | example |
original source | original api-header-file from distribution | myapi.h |
#1 start frontend | create standardized-COMPILER-input-files | ... |
extension-tool | __parser__(…) | LibMyApp.h | ... + LibMyApp.h ... |
class-tool | class.def | MyClass.h ... | ... + MyClassC.c/h ... |
doc-parser | docu.something | myapi.doc | ... + myapi.doc |
finish frontend |
#2 start compiler | create standardized-META-input-file | LibMyApp.h |
meta-compiler | LibMyApp.h | LibMyApp.meta | ... + LibMyApp.meta |
missing-compiler | LibMyApp.meta | MissingDefs.c/h | ... + LibMyApp_include.h |
finish compiler |
#3 start backend | create standardized-LNG-input-files | lng.def = tcl.def ... |
code-S-gen | ... + lng.def | LibMyApp_LNG.lng | MyAppC_tcl.c/h/ext ... |
code-C-gen | ... + lng.def | MyClass_LNG.lng | MyClassC_tcl.c/h/ext ... |
code-DOC-gen | ... + lng.def | LibMyHeader.doc ... | LibMyHeader.doc ... |
finish backend |
#4 start LNG | create target-API-package | ... |
LNG-compiler | files step #3 | LngApp.ext | LngMyApp.ext |
back
theCompiler