Micro Autocode

Micro Autocode is a high-level language designed for use on very small microcontrollers. Initially only the Atmel AVR1200 was supported, although options now exist to enable code to be written for many of the other AVR devices. In the longer term other microcontroller families will be supported.

Why do I need to learn a new language?

The limitations of very small microcontrollers: small or non-existant RAM and very limited hardware stack, makes them unsuitable for running code produced with all current high-level languages. If it was possible to find a compiler that could target such a device, then the code you were forced to write would be highly constrained and you would lose many of the advantages of writing in such a language. In fact the Gnu gcc compiler suite supports the AVR family, but it does not support the smaller members of the family, such as the 1200.
Up until now the only alternative to high-level languages such as C or Forth has been assembler. Coding in assembler is a slow process, prone to producing many more bugs than a higher-level language. However it is efficient and makes the best possible use of the small amount of program memory available.
Micro Autocode is higher-level than assembler but lower-level than C. It allows you to use the full capabilities of a high level language that is well-matched to the device you are targetting. It has modern facilities tuned to the requirements and limitations of the hardware.

Why waste code space with a compiled language?

The Micro Autocode compiler produces fairly efficient code that is related to the assembler code it compiles into in a straight-forward manner. It is easy to convert parts of a program into assembler for added efficiency if required, even on a line-by-line basis. You don't need to do so, however, unless you really need to wring every spare byte out of the program. Micro Autocode programs may be upto 25% larger than the equivilent hand-optimised assembler.
Another reason that you will want to avoid assembler is bug-count. The number of bugs per line of source-code has been fairly constant for decades - whatever language you use. That means you should get five times fewer bugs with Micro Autocode than with assembler.

A language with a history...

This is probably the oldest high-level language there is. Autocode was written for the Mercury Mark I computer in 1954. For a description of that language see The Computer Journal, April 1958 and October 1958. (For those who believe that FORTRAN was the first compiler, you're right. Mercury Autocode was interpreted.) Micro Autocode follows the spirit of its parent, and in the main uses the same syntax. It calls functions chapters and it doesn't have a multiplication operator (but it still does multiplication.) When you program in Micro Autocode you are using a language that is half a century old.

...but with a thoroughly modern pedigree

But of course a lot has happened in the last fifty years, not least in the field of computer language design. In developing Micro Autocode we were careful to ensure that while the language should be based recognisably on Mercury Autocode, it must provide the sort of convieniences that modern programmers expect while ensuring a close relationship with the underlying hardware. The differences from the Mercury dialect are as follows:

No floating point.
Multi-character variable names.
Textual labels.
Restricted multiplication and division (only by constants, and only by powers of two.)
A "while" statement.
A new type of chapter - "service" - for interrupt routines, and a new instruction type to set the start-up vectors.
The use of brackets enclosing variable indecies to eliminate ambiguity.
Variables tied to specific hardware types.
No read, "?", print, space or newline instructions.
No reset instruction.
The ability to insert assembler instructions in-line.
Support for bit setting and testing operations.
Compiles to assembler code and therefore ties into the Gnu compiler collection.

The state of play

The compiler is complete and functional. It needs some field testing before I am willing to call it beta quality, but I want it used for real-life projects, so rest assured that I will respond to bug reports promptly.
There are many possible directions that this project could take from here. I will be interested in any suggestions that you might have. My current intentions are:

Make ranges calculate their parameters at the end of the loop, each time round, rather than at the top, once. Increasing run-time, but decreasing register usage.
Just maybe, implement a block-structured IF.
Support planting literals in eeprom and flash. (The 1200 can't load flash.) Currently you need to use a verbatim block to insert literals.
Literal identifiers and included files. (I use the gcc preprocessor currently, but it isn't ideal.)
Support for output in C, to allow the migration of a project to a more powerful MCU.

What you need to get started

You will need:

The Micro Autocode compiler source-code.
A C compiler for your workstation.
The Gnu bin-utilities targeted for the AVR, built for your workstation.

The source-code of the Micro Autocode compiler can be downloaded from the Sourceforge project page.
There is also a Cygwin executable available for running under Windows. For that you will need:

The Micro Autocode cygwin .zip file
An application to unzip it.
The basic Cygwin package.
The Gnu bin-utilities targeted for the AVR, built for Windows or Cygwin.

It should be possible to get Micro Autocode compiling natively for Windows, currently there is a header file problem. It compiles perfectly well under Cygwin.

Last Edited - R Urwin - 27 September 2004