Yomal

There are many programming languages for the Atmel AVR line. Of course we have the official assembler which I already gave some thought in another chapter. And there is the gcc compiler which is for free but also hard to get and quite difficult to install.

For the short term I settled with the gavrasm assembler. It seems to fit in with my needs. Still, the assembler is based on the Atmel assembler and it is not my cup of tea. I could set out to write yet another assembler, based on the AVR instruction set. And it crossed my mind to do so.

But I would end up with yet another programming tool that is not suitable for the 21st century. So I came up with something new. Something that is intermediar to assembler and compiler. I call it:

Yomal is too complex to be called an assembler, but can barely be seen as a compiler. It's the lowest level compiler you can image, supposing we pretend that C does not exist (which shouldn't be too difficult).
Yomal will be a compiler with:

Some type checking
Only few datatypes
Case sensitive (uppercase keywords)
Local variables
No goto statement
Easy arithmetic
VERY few keywords

Yomal is strongly influenced by Modula-2. It's not a copy or a special version of it. But if you are familiar with Modula-2 or Oberon (or Pascal) you will feel at ease with it quite fast. If you need a Modula-2 for a microcontroller, check out the m4m project (via Fruttenboel Home).

This is a dynamic page. It will change irregularly. I will try to keep as much 'old' information as possible, so that you can see how the compiler evolved. As in my other pages I want to show that things mature. It's easy to publish a project as one page, after the last bug has been removed. But it's more honest to also show every step of the way. This is unusual on the Internet. Most of my colleagues prefer to pretend they always succeed in their first attempt (or erase the traces of it, after failure).

It doesn't matter if you build a compiler or an assembler. You just cannot do without a symbol table. It is the heart of the matter. So a carefully crafted symbol table will be the difference between success and failure.
The symbol table needs to know:

all AVR ports and registers
the global constants and variables in the program
the procedures in the program
the local constants and variables of a procedure

And since a local variable only exists inside a procedure, the symbol table must expand when a procedure is entered, but it must shrink when the procedure is exited. Also, the symbool table must be searched from the last element backwards.

The doubly linked list has the following form:

No matter in which 'node' of the linked list you are, you can always go either way: back or forth. We need to go forth for entering new symbols: they must be unique. So for this we start in the far left and end in the far right. But for checking the validity of an operator upon a data type it is better to start in the far right, and work our way back. So we need the two pointers (next and previous) plus two global variables (firstSym and lastSym) that remember the leftmost and rightmost elements of the symbol table.

This is the normal linked list. it is similar to the doubly linked list (above) but here is no 'previous' pointer. Only the 'next' node of the list is known. So you can only go through this list from left to right. In most cases, this is more than enough. It's just that the AVR contains zillions of registers and ports so a bare symbol list will already take up close to 100 elements.
And the program will mainly use the local symbols and the global program elements. So a search for a program symbol will need to go through a zillion of AVR specific symbols before the program code symbols get in sight. So from this point of view, the doubly linked list looks more promising.

Still, we could go for a third option, somewhere in between:

the uniqueness of symbols is checked from left to rigth
new symbols are entered in front of the AVR specific symbols

This way, we can:

check for uniqueness of symbols
find program symbols easy and fast
do with a singly linked list

I'm still thinking what to use: a doubly linked list that is searched and filled easily, or a simple linked list that needs a set of boundary conditions to be able to fill. Still thinking...

The bigger AVR's can address

128 k of ROM
32 k of RAM
32 k of EEPROM

This all adds up to less than 256 kilobyte of addressable storage. My Mocka compiler uses 32 bit CARDINALs. So we have some headroom. And I will fill that headroom up and gain something in the process. Yomal will not address bytes or words of memory space. It will refer to bits. This enables me to easily manipulate control register bits. One example:

Property	Value
Processor	ATmega8515
Control bit	PUD
Register	SFIOR
Bit nr	2
SFIOR address	$50
PUD address	$502
PUD aliasses	PUD SFIOR.2 $502 $50.2 Any other defined alias

Project abandoned, in favor of M4M

Page created on 27 april 2007 and

Page equipped with FroogleBuster technology