Lotta
language & compiler
Lotta is a modular, simple
language, in the spirit
of oberon and modula-2
Compiler written completely in oberon-2, using
optimizing oberon compiler
First compiler target will be Oric Atmos microcomputer with MOS 6502
cpu.
Port to other 6502 based cpu's and
PIC/Atmel microcontrollers are planned.
PC/Linux port also will be available.
Lotta language full documentation
is not available, but will be published
soon.
I can write only few things about Lotta yet:
Small code
Lotta designed to produce very
small and fast code. I hope it will even be useful to participate
programming competitions with size limit 1 or 4 kb (like one at http://ffd2.com/minigame)
Runtime
information
Because of that, information available at runtime should
be minimized as possible. No pointers, no dynamic arrays, only
static variables are allowed. Heap usage minimized as
possible. In fact, heap is useless for Lotta
Zero
page
Compiler should allow generating code which will use zero
page intensively. This will allow extremely
decrease resulting code size. In this case, returning to
host operating system (for instance Tangerine Basic)
may be impossible.[5]
Smart
linking
Lotta compiler should use new
technique, introduced by fpc
developers [1]
called smart linking.
That means, only procedures which called from the other
parts of code are compiled.
Difference is, that in case of fpc that is done by
translating each procedure into one object file.
In Lotta, it is done on the parser
level, parser just ignore unused procedures and does not translate them.
This allows decreasing code size efficiently.
Lotta is a modular, strong typed language. It
performs strong type checking at compile time.
Module procedures, variables, types and constants may be exported or
exported as read-only [4]
Aliasing of module names is not possible.
Function procedures may return
two results, possibility to return array or record variables.
Because Lotta is not object oriented, enumerated types are allowed [2]
When calling procedure, only variable parameters accepted, not
expressions, because it is easier to make mistakes, and
there is no possibility to view expression result while debugging,
because it isn't assigned to any of declared variables
Procedure parameters could be by pointer (VAR) and read-only.
One pass easily retargetable compiler
In the past, two main types of compilers were avaiable.
In first case, parser generates an object code (or assembler source)
directly.
In second case, parser generates intermediate representation. It
thereafter at second pass parsed again and translated to the target
machine native code.
In this case compilation are more time consuming because of second
pass, but on the other hand task of writing another backend simplified,
because there is no need to change parser part of compiler, instead
only new backend should be written.
At that time, memory was limited, so, there was many multipass
compilers even for languages, which design allows to write one pass
compiler. First Modula-2 compiler made 7 passes to compile source code.
Per Brinch Hansen wrote a book about how he wrote multipass pascal
compiler for computer with only 64 kb ram available. [3]
Now memory is not that limited and now possible to translate
intermediate representation into target code on the fly
[1]
"FreePascal BuildFaq", Marco van de Voort
[2] "From
Modula to Oberon", Niklaus Wirth
[3] "Brinch Hansen on pascal compilers", Per Brinch Hansen
[4]
"Oberon-2 report", H. Mössenböck, N. Wirth
[5] "Pravetz-8D manual"