The core concept
e# is a tool language that should be suitable for all kind of embedded-related development activities, starting from defining the device architecture and its instruction set, documenting device specifics and finishing with programming the device with a developed application. Instead of allowing the developer to write an arbitrary language constructions and pushing the compiler to made an executable out of it, e# should let a developer (a device vendor) to express the device resources, capabilities and constraints in the language terms. These capabilities and constraints than are applied to the application sources, simulation model and executable image. If any of the constraints are violated the e# builder would produce error, either compilation, simulation or code generation time.
It should retain major assembler’s capability to express application’s logic in terms of processors instructions, where each statement is translated into known number of know instruction of a given CPU/MCU.
The language should allow writing generic libraries for a given architecture operating on common architecture-wide facilities expressed in terms of a lowest subset of ‘abstract device instructions’ declared for the architecture, which then, at application level, are implemented/instantiated for a given MCU.
Shortly e# can be defined as a compilable code generator – at first sources are compiled then they are executed and, as a result of this execution, application code is generated. Compilation should not generate any target device code, it should only verify syntax and generate instructions on how to generate target device code. e# definitely is a high level programming language, however, applications written in it should still be able to use features of a low-level programming language, such as access to all available device resources.
It is believed that the concept could be applicable to RISC, CISC and VLIW architectures, although, the latter one will require more efforts on describing the device.
Language characteristics
The e# language, as I see it, should:
- be device independent
- be based on object-oriented paradigm
- have strict typification
- suit well for writing device definition and instruction set definition
- provide capabilities for hierarchical device definitions
- support concept of single processor instruction per one language primitive
- provide mechanisms for control over code generation, linking and resource allocation
- provide ability for verifying constraints imposed by design, device, architecture (and others) at compilation and simulation time
- fit for basic simulation needs
- allow direct manipulation with device resources
- provide capabilities for ‘transparent code generation’
- allow writing device-independent architecture-specific libraries
- provide encapsulation capabilities
- provide support co-processor architecture
The e# builder should allow debugging all stages of build process, except, of course, the compilation stage.
One Comment