This is an old revision of the document!
Table of Contents
TinyC for the SD-8516
Introduction
This is not intended to be a general purpose programming language. It is intended to be the language I write the general purpose programming language in. However, I keep running into bugs. I am not sure if I should keep improving it or whether it's time to re-write it.
TinyC refers to V1 (tinyc.asm) and V2 (tinyc.c), which is the same as V1 but written in C. V1 is intended to compile V2, and then we have self-hosting C. Thus, this TinyC should be more like the “B” language in it's feature set, and in the idea that it is intended to compile a version of itself written in C. From there, we can iterate on the C compiler and make it better.
V1 Current Feature Set:
- Expressions with precedence
- Local variables
- if/else/else if
- Comparison operators
- while
- break/continue
- Multiple functions + function calls
- Function arguments
- Pointers (read, write, address-of)
- Array indexing
- char* (8-bit access)
- String literals
- Hex literals
- Character literals
- Comments (//)
- Global variables
- Builtins (putchar, getchar, halt, yield)
This is enough that I was able to start writing functions in C like abs, min, max, strlen, strcmp, atoi/itoa, and so on.
Function Library
History
A self-hosting C compiler had been my goal for quite some time. But I didn't know how to write one. I hacked out a BASIC first, then followed some guides and source code to get a Forth running. But C eluded me for several months. Eventually I was able to leverage what I had learned doing BASIC to get a parser that could compile int main(void) { return 0; } and emitted LDA #0 and RET. The debugger was simply printing the return value. The rest of the story is found in the TinyC Developer Diary. Mainly so I don't forget what I learned, as this project has gotten quite big.
Issues
The big issue is that I don't really know what I am doing. Meaning, it's really no issue to mechanically process a script and write an interpreter or compiler for it, if you just start coding. The real issues will be operational, later on. Here, the issue is that the compiler doesn't know where to compile itself to. TinyC v1 lives in bank 1, TinyC v2 lives in bank 3 (because that's where it was compiled). So should it compile to bank 1? Well, originally it wasn't written this way but when you talk about it like this the solution seems easy; have an int variable such as target_bank and we just compile into that. What would really be good is to compile into an area but the code itself is targeted for a different bank.
What is even better is if I could write relocatable code. You know, simply writing this out all gives me ideas. Relocatable code! Could be interesting. Ok let's write down some ideas– Relocatable Code
