Newer
Older
Import / research / reflection / README.md

KAI Programming Language

Overview

The language is designed to be efficient yet safe by design. This means that it should be impossible to create unsafe code. But this shouldn't require sacrificing speed.

Programmers know how to write efficient code in languages like C, but then it can be easy to make a mistake and for the code to be unsafe in unforeseen circumstances.

With C/C++ and similar languages, the burden to be satisfied that the code is infact safe is placed on the programmer, while a programmer will use logic and reason to determine this, this is a task which can be automated with tools like static analysers. But neither are fundamental to the language, and the language doesn't provide any aide to these automated tools.

Other stategies to achieve safety are to do checks at run-time, but this has an overhead associated with it. For example, array access using bounds checking. In a C program, when looping over an array, a programmer can ensure that for the iterations that it will only iterate on valid array indexes, then each access doesn't need bounds checking, whereas a run-time check would be a penalty for every access that is not needed. A better designed language and libraries would iterators which can achieve the same results as what a C program achieves, but provably correct at compile-time, without requiring static anaysis or run-time checks.

To work towards creating this language, a number of steps and tools are required to boot strap this.

  • A front-end parser is needed for reading the code and outputting an IR (intermediate representation) which captures the AST (abstract syntax tree).
  • A VM for interpretting and running the IR
  • A JIT/back-end code generator for converting the IR in to target specific machine code

Usage

Front-end parser:

./build/translator INPUT.kai

Currently it can in memory construct an AST of the program and can spit out
VM asm of expressions in the code. But it doesn't create a full VM asm listing
of an entire program.

Assembler:

./build/asm INPUT.asm OUTPUT.bin

Can convert textual VM instructions in to a binary VM program that can be executed
by the VM.

Currently the assembler is attempting to create a 'fat' binary which includes a
.text section and .text_x86 section which are a stream of VM instructions and
native machine code respectively.

VM interpreter:

./build/vm INPUT.bin

Can execute the program via the VM. (Currently doesn't use the native machine
code section of the binary).

Future Work

Native code generation is only for x64 at the moment, but could add other targets. It should however be platform agnostic, so only need to compile once for all OSs which are x64.

Probably the VM could create the native section in the binary JIT, eg at time of first execution for the specific machine. Perhaps could cache it somewhere outside of the original binary. That might be a system setting.