About The Project

Tin is a structured, imperative and procedural programming language designed around the RISC-V instruction set architecture. It is aimed mainly at applications running on embedded systems, but should be suitable for applications outside of this field.

This is a group project, originally as an assignment for the University of Lincoln. The project itself is a language built for the RISC-V architecture.

(back to top)

Built With

Flex 2.6.4
Bison 3.5.1
GCC

(back to top)

Getting Started

Follow the prerequisites and installation guidance to get started, once complete you are able to start making your .tin files.

Prerequisites

Run the following command to fetch all of the required packages in order to build the toolchain:

$ sudo apt-get install build-essential flex bison binutils-riscv64-linux-gnu qemu qemu-system-misc qemu-user

Installation

Clone the repo

$ git clone https://github.com/The-Tin-Foil-Hat-Society/tin.git
$ cd tin

Add the standard library to PATH
```
$ PATH="$PATH:$(pwd)/std"
```
Build the project, by default the release version is built
```
$ make tin
```
Build the debug version
```
$ make tin build=debug
```
Compile your .tin file
```
$ ./build/tin file-name.tin
```
Run the executable through QEMU
```
$ qemu-riscv64 ./file-name
```

(back to top)

Usage

Call tin -h for CLI usage.

This language is currently for the RISC-V architecture, the usage of the language an be seen in the documentation or the working examples.

For more examples, please refer to the documentation.

(back to top)

Testing suite

The following guide assumes you have completed getting started and can build .tin files, an important note is to not use the debug version as the clean-up is not designed to handle all the extra files generated or the verbosity outputted in the console. When writing a new test keep in mind that the output of the executable is tested so wherever possible include prints so that information is logged to the console that the tester can then check the differences between. When running the tester if you want a more verbose output or the expected outputs on failed tests make sure to use the ‘-e’ / ‘--expected’, ‘-v’ / ‘--verbose’ arguments in the command line make note that when using verbose the expected output of failed tests is show also.

Steps for adding new tests

Create a new .tin file with the code that you wish to test
```
$ cd testing/unit-tests directory
```

Compile the file and check output is as expected

$ cd ..
$ ./build/tin ./testing/unit-tests/file-name.tin

Run the executable through QEMU and check output is as expected
```
$ qemu-riscv64 ./testing/unit-test/file-name
```

Store file output

$ qemu-riscv64 ./testing/unit-test/file-name > ./testing/expected-outputs/file-name.txt

Run the automated tester
```
$ cd testing
$ python3 test.py
```

If the tests pass you will be told that everything worked and if there is a failure for a test, then this will be outputted to the console with which test failed and the expected output of the test if using verbose or expected output mode.

(back to top)

Roadmap

Standard Libraries
Optimisation
Implementing #include
Memory Tools
Non-RISC-V Interpreter

See the open issues for a full list of proposed features (and known issues).

(back to top)

Contributing

Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.

If you have a suggestion that would make this better, please fork the repo and create a pull request. You can also simply open an issue with the tag "enhancement". Don't forget to give the project a star! Thanks again!