Eugene Hutorny » e#

Random theses

Eugene — Fri, 15 Sep 2006 22:09:28 +0000

This post collects and organizes discussion theses posted on different forums.

MCU Models

Despite it is not explicitly spelled out, assemblers and C-compilers do use one or the other kind of MCU model, defined in terms of the programming language (assembly, C or preprocessor). These models are ‘flat’ (set of constants or static variables). These models are often incomplete and can be easily misused without any compilation error.
Linkers and simulators use another way of defining the same model and doing it in other, different languages with no or very little documentation support.
e# will give ability to define a formal, self-descriptive MCU model once and open it for use everywhere ??“ in compiler, application, and simulator. This indeed does not negate the need to learn the hardware. Instead e# will provide a formalized addendum to the device datasheet.
Defining MCU model in the same language as the program is written will open up possibilities hardly achievable in the current tools.

Cost of abstractions

All proposed abstractions are abstractions of the tool language. They will be constructed and executed on the host computer. There will be no abstraction one would have to use on the device. One still will be able to program in terms of instructions, and on top of that, may define abstractions for the device in extents of available device resources. For example, one would be able to define (and implement) an interface method call using whatever calling convention is appropriate and use it as if it were a HLL language.

Generic MCU

Many parts in an embedded application (such as state machine, math, conversion, etc.) can be written for a ‘more generic MCU’ and these parts can be transferred to other MCU that fit under the same ‘generality umbrella’. This will give developers freedom to make such choice – either writing with very limited very generic MCU and have highly portable code or writing for a given MCU and have more efficient and, of course, less portable code.

e# language vision as an ‘embryonic development’ story

Eugene — Sat, 09 Sep 2006 12:41:16 +0000

In this post I present my vision of e# reflected through history of assemblers. For each stage in the assemblers’ history I am providing presumptive equivalents in e#, incrementing the complexity of each next example.

Statements, reused from the previous step are grayed out to focus you attention on new features. Bold indicates possible keywords of e#-tool language.

I hope this way of expressing will help the reader to understand my idea and an approach on its implementation.

‘Ancient’ programming
Instruction codes are directly placed to the current location of the executable image as binary values.





 


B'00 0000 0000 0000'


B'00 0000 0000 0000'


B'10 1000 0000 0000'

Mnemonic assembler
Instead of writing in binary codes, commands are replaced with their mnemonic names. Mnemonics are defined with keyword instruction and implemented as a placement of proper instructions codes





instruction nop { (B'00 0000 0000 0000'); };


instruction goto(bit11 addr)


{(B'10 1000 0000 0000' | ( addr & B'111 1111 1111')); };


nop;


nop;


goto 0;

Symbolic assembler
On this stage addresses are replaced with symbolic names and instructions operate on names rather then on addresses. A new essence is introduced – label. Instruction goto renamed to go due to change in notation and it is defined for the label only, thus developer can not apply it for a data address.





instruction nop { (B'00 0000 0000 0000'); }


instruction label.go


{(B'10 1000 0000 0000' | (this & B'111 1111 1111' )); };


 


label there;


nop; nop;


there.go;

Relocatable assembler
This approach has introduced sections – logical portions of code with unspecified absolute addresses¹. A new essence is introduced – section. Section is started by specifying its class (type) and optionally name. Section scope is denoted by braces. Named sections are accessible as build-time objects, some of their properties (such as size, absolute addresses) can be made available as run-time constants.





instruction nop { (B'00 0000 0000 0000'); };


instruction label.go


 { (B'10 1000 0000 0000' | (this & B'00 0111 1111 1111' )); };


instruction file.inc


{ (B'00 1010 1000 0000' | (this & B'00 0111 1111' )); };


data  mydata  { file myvar; };


code {


 label there;


 nop; nop;


  there.go;


  myvar.inc; };

Infix assembler
Assemblers of this kind have drifted from operation mnemonics and fixed-column format toward to more ‘natural’ syntax, especially for assignment and arithmetic operations. This example illustrates alternative definition of instruction inc².





instruction nop {(B'00 0000 0000 0000'); };


instruction label.go 


{(B'10 1000 0000 0000' | (this & B'00 0111 1111 1111' )); };


instruction file.inc 


{(B'00 1010 1000 0000' | (this & B'00 0000 0111 1111' )); };


instruction file '+=' (const 1) { this.inc; }


data  { file myvar; };


code {


label there;


nop; nop;


myvar += 1;


there.go; };

Meta-assembler
Meta-assemblers were aimed making the language device independent by providing a separate, replaceable device and instruction set definitions. New concepts are introduced – device definition and application’s target device.





device PIC16F84;


  instruction nop {(B'00 0000 0000  0000'); };


  instruction label.go 


  {(B'10 1000 0000 0000' | (this & B'00 0111 1111 1111' )); };


  instruction file.inc


  {(B'00 1010 1000 0000' | (this & B'00 0000 0111 1111' )); };


  instruction file '+=' (const 1)


  { this.inc; }


end device;


application myapp for PIC16F84;


  data  { file myvar; };


  code {


    label there;


nop; nop;


   myvar += 1; 


   there.go;  };


end application;

Object-oriented meta-assembler³
This stage contributes object-oriented approach to the device definition and application programming. Each device resource is defined as an object of a class, these classes forms a hierarchy and encapsulate implementation details.

Application defines and uses build-time abstractions. Mapping of these abstractions to MCU resources is explicitly provided by the developer.





device PIC16F84 extends PIC16;


 instruction nop {(B'00 0000 0000  0000'); };


  class label


  instruction go 


  {(B'10 1000 0000 0000' | (this & B'00 0111 1111 1111' )); };


  end class;


  class subroutine extends label


     instruction call


     {(B'10 0000 0000 0000' | (this & B'00 0111 1111  1111' )); };

  end class;


  class file


    constructor { reserve(1); }


     instruction inc


     {(B'00 1010 1000 0000' | (this & B'00 0000 0111  1111' )); };


     instruction '+=' (const 1)


     { this.inc; }


  end class; 


end device; 


application myapp for PIC16F84;


  class mycount extends private file


    public instruction inc;


  end class; 


  data  { mycount myvar;  };


  code {


    label there;


    nop; nop;


    myvar += 1; 


    there.go;  }


end application;

e#
Proposed language will support capabilities of all mentioned assemblers and in addition will provide ability to program builder behavior for all kinds of activities: resource allocation, image verification, simulation, programming (the device), documenting and others. This example illustrates statements for simulation-time verification and documentation⁴. Device definition provides code for validating currently selected bank (page) against the bank (page) intended for access and raises a error if a mismatch is detected. This technique will help to detect banking errors on early stage. Application uses simulation-time code to validate initial state of a variable.





devicePIC16F84 extends PIC16;


   instruction nop {(B'00 0000 0000 0000'); };


   class label


   instruction go 


  {(B'10 1000 0000 0000' | (this & B'00 0111 1111 1111' )); }


  sim { if !  pageCheck(this) then raise error('"go" paging error);  }


  doc { 'GO is  an unconditional branch. The eleven bit immediate value is loaded into PC  bits <10:0>. The upper bits of PC are loaded from PCLATH<4:3>. GOTO  is a two cycle instruction.'};


   end class;


   class subroutine extends label


    instruction call


     {(B'10 0000 0000 0000' | (this & B'00 0111 1111  1111' )); }


  sim { if !  pageCheck(this) then 


      raise error('call paging error'); }


  doc { 'Call  Subroutine. First, the 13-bit return address (PC+1) is pushed onto the stack…'};


   end class;


  class file


    constructor { reserve(1); }


     instruction inc


     {(B'00 1010 1000 0000' | (this & B'00 0000 0111  1111' )); };


  sim { if ! bankCheck(this) then raise error('banking error'); }


     instruction '+=' (const 1)


     { this.inc; }


   end class;


end device;


application myapp for PIC16F84;


  class mycount extends private file


    doc {  'mycount is a GPR with restricted access')


    public instruction inc;


   end class;


   data mydata { mycount myvar; };


  if pic.banks[3].present then mydata.bank :=  pic.banks[3];


   code {


  sim { if myvar.value  <> 0 then 


    debug.print 'myvar is not initialized!'; }


     label there;


    nop; nop;


     myvar += 1; 


    there.go; }


end application;

¹In the traditional approaches a linker (loader) picks a ‘good enough’ space for each section and places codes in that space. Then it goes trough a fixup-table and adjusts instructions according to actual addresses. e# will implement a different technique – since all build steps (assembling, linking, etc) will be performed in a single run, the linker routine will operate on the same internal representation of object created by the compiler routine

²In this example I did not use postfix form ‘++’ intentionally, in my opinion this kind of syntax does not improve readability.

³I am not aware about existence of such in the real world

⁴Documentation samples are taken from PICmicro?„? Mid-Range MCU Family Reference Manual

Benefits of using e#

Eugene — Sat, 02 Sep 2006 19:11:21 +0000

I envision the following benefits of using e#

It will allow writing better quality code in shorter time
It will reduce maintenance cost by providing abilities for regression testing (on a simulator or in-circuit debugger)
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	good¹

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

e# roadmap

Eugene — Wed, 30 Aug 2006 15:48:16 +0000

Refine vision
Establish requirements
Design a device metamodel

Make key design decisions on the language, define a protolanguage
Exercise with metamodel and protolanguage on different platforms
Refine vision, requirements, metamodel, protolanguage
Design the language, write BNF
Pick a BNF subset covering the protolanguage and build a protocompiler
Exercise with protocompiler on different platforms with different applications
Make a hierarchical tree of few architectures and devices
Refine vision, requirements, metamodel, protolanguage, BNF
Write e# language reference
Develop a compiler
Design models for few architectures and develop units for few devices
Ooh!

Concept of a new PL for embedded applications

Eugene — Mon, 28 Aug 2006 23:39:46 +0000

Preface

I would like to discuss with you my ideas on new programming language for embedded applications, denoted further as e#. I value your time and therefore in this post I am trying to be short and precise as much as possible.

	Preface	1
	The core concept	2
	Vision in examples	3
	Concept of execution	4

My goals are:

Share ideas and get opinions from experienced people;
Stress the idea with criticism;
Find associates for developing the language;
Design a language that would help other developers to follow OOD paradigm and give them better ability for reusing once implemented objects.

The new language should (is expected to):

bring a disciplined approach to the "programming in a small" field;
suit for most of MCU platforms and experimental processors;
provide a good replacement for different ASM-associated languages ;
give a tool for automated application testing on a simulator;
provide better porting/multitargeting capabilities;
reduce impact caused by moving to another hardware platform;
benefit to all parties involved in developing embedded applications.

Other languages considered

JAL, NASM, TAL, HAL, ISDL, VHDL

Definitions

Device language – its statements, being translated, are actually executed by the device(s)
Tool language – its statements are executed by a development tool on a host computer.
Builder – a development tool that controls all stages of a build process, e.g. compilation, linking, etc.