Skip to content

Benefits of using e#

I envision the following benefits of using e#

  1. It will allow writing better quality code in shorter time
  2. It will reduce maintenance cost by providing abilities for regression testing (on a simulator or in-circuit debugger)
  3. It will reduce impact of migrating to another device/platform

e# will be more restrictive to human errors and misusages. It will generate errors at places where a regular assembler gives no warning, such as use of literal instead of address (movf myconst,F) use of improper address (goto myvar), using a flag on a wrong register (bsf OPTION,GIE) and so on.

e# will provide facilities for ‘in-place’ validation which can be performed in scope of a simulator run or under an in-circuit debugger. For example, each call to a square root routine can be validated against square root calculated by the e# builder upon actual parameters passed to the routine. Developer will be able to program such validations in e# and apply appropriate action if an invalid condition is detected (log a message, raise an exception, etc.). Another example ??“ a delay routine can be validated against expected delay.

e# will provide facilities for automated testing (unit, integration, etc). Once established, these tests can be used for regression testing, allowing early problem detection when a new firmware version is in work (application maintenance) or when application is being moved to another target device (migration). These facilities will provide great help for debugging code, although they will not replace a visualized interactive debugger.

e# will give ability to use essential level of abstractions when designing and implementing applications and still giving developers full control on costs and penalties contributed by those abstractions. For example, developer will be able to define a ‘function call abstraction’ and implement proper mechanism for passing parameters and returning the result. Once it is done, the function call can be used in a similar way it is used on HLL and compiler will control if it is used as designed at syntax level, while developer may program code to verify it at semantic level.

e# will provide ability to program for an ‘abstract MCU’. Yes, I know, MCUs are different, but nevertheless, I believe, it is possible to define a generic MCU model with a most common set of registers and instructions, such as load a literal, move, add, subtract, branch etc. This generic MCU model will not be generating any machine instructions leaving this responsibility to a model of a real-world MCU used in the application. A library routine (such as 16-bit wide addition), written for an abstract 8-bit MCU it terms of abstract MCU instructions, will be instantiated in the application with instructions, provided by the model of actually used MCU.

e# will provide another way of delivering device notices, cautions, silicon errata to the developer. Until explicitly suppressed each notice associated with the device will be printed to the compiler output. These notices may have complex logic for determining if the underlying issue affects the application. This will help identifying problems before they happen and will simplify the migration path.

e# MCU model will be yet another source to learn the target device either by inspecting the model source or by exploring the device in IDE. Since the model will be defined in a programming language and accessible to IDE as a set of objects, exposing the model to IDE will be a rather routine task.

e# will provide facilities to control object vs resource allocation, eliminating need of separate linkers with their own ‘kind-of-a-language’.

e# will be better suitable for modular and/or OO design providing essential facilities for modularity, encapsulation, and objectivity.

e# will provide ability to debug process of code generation

Besides features not yet available in other languages, e# will address several shortcomings of assembly and C languages.

Table 1.e# vs ASM and C

Language feature ASM C+ASM C e#
Syntax control poor poor moderate good
Modularity poor moderate moderate good
High-level abstractions poor moderate moderate good
Access to the device model moderate moderate moderate good
Low-level coding (in instructions) good moderate poor good
Access to link-time variables moderate moderate poor good
"Transparency" of generated code good poor poor good
Portability poor poor good good1

1 e# will not solve efficiency vs. portability dilemma, however, it will shift this solution from the tool selection stage to the design and implementation stage.

3 Comments

  1. edt wrote:

    Very interesting ideas. I’m especially interested in the automated testing facilities and grouping/factoring of data (like inline simulation controls).

    I’m curious, though, what langs/tools e# would be intended to interface with and what shortcomings it would attempt to do away with in those tools it would replace. For instance, syntax seems very similar to C, but you contrast e# to asm and hardly to C.

    I also had a possibly related idea. I know our company would have many uses for an efficient system to ‘port’ MCU code to other languages for simulation. We have a program to interact with networks of our products and there’s been some random discussion about online demos of our product. These environments need to simulate the devices, but the devices would only be represented as objects in the program with much more logic. A very-high-level language such as e# might be able to generate simulation object code if that sort of need comes up often for most companies.

    Saturday, September 9, 2006 at 01:18 | Permalink
  2. Eugene wrote:

    1. Interfaces with other languages

    I envision it in this way: e# will provide (a) language constructions for interfacing with code compiled with other languages, such as assemblers and C; (b) ability to implement (program in e#) semantics for those language constructions. This approach will give essential degree of freedom to the developers ??“ they would be able to write their own implementation (or reuse third party code) if interfacing is not provided by the compiler vendor or provided implementation is not found satisfactory.

    Also, I am thinking about interfacing with VHDL, but this is the question of the distant future, and, I think, would be the matter of bringing e# simulation model inside VHDL as an externally implemented entity

    2. Interfaces with other tools

    Other tools??¦ Do you mean IDE? At this time I may only say that Eclipse is the first candidate to integrate with.

    3. Shortcomings

    Yes, you right – I am not opposing e# to HLL languages. If there is an HLL compiler for the target device producing code that fits the device resources, and the code performs the task ??“ why should one ever look for other tools/languages?

    e# is aiming developers for whom writing in assembly or C/assembly explosive mix is the only choice left. I have collected shortcoming I see in ASM, C and C+ASM in the table 1. I expect e# will address all these shortcomings.

    Sunday, September 10, 2006 at 21:45 | Permalink
  3. edt wrote:

    No, by tools I meant compilers, simulators, in-circuit debuggers, etc. Possibly IDE’s, too, but I wouldn’t consider an IDE a development tool in anywhere near the same sense as those.

    VHDL is a cool idea, too.

    Monday, September 11, 2006 at 18:01 | Permalink

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*

*

This blog is protected by dr Dave\'s Spam Karma 2: 197 Spams eaten and counting...