Eugene Hutorny

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

¹ 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.