This is an old revision of the document!
Table of Contents
Programming in C for the SD-8516
Self-hosted TinyC v1
Yes, you can write C code for the SD-8516. However there are certain… limitations of the self-hosted project. Staying positive however, you can do quite a bit.
| TinyC V1 can do.. | Not available |
|---|---|
| Builtins (putchar, getchar, halt, yield) | no enums |
| int and char* (8-bit access) | no inits i.e. no int a = 5; |
| Expressions with precedence | no typedef, no casting, no conversions |
| Local variables | no multiple return types (int only) |
| if/else/else if | no static, extern, register, volatile, const |
| Comparison operators | no && or ||, no %, no bitwise ops |
| while | int *p; p + 1 adds 1 byte, not 3 |
| break/continue | no sizeof |
| Multiple functions + function calls | no function pointers |
| Function arguments | no varargs |
| Pointers (read, write, address-of) | no void type |
| Array indexing | no int a[10]– pointers only |
| String literals | no type checking |
| Hex literals | char arithmetic doesn't promote to int |
| Character literals | no standard library |
| Comments () | no dynamic memory |
| Global variables | no file IO and no access to system INT libraries |
What this is really is more of a baseline C you could write a better compiler in. That's where we are right now. Secondly, this is not packaged anywhere yet; I don't know if I want to release it because it is really not a very robust program; however, I very likely will, sometime in the fall.
Self Hosted TinyC v2
v2 is v1 written in C. It compiles but there are issues I am working on.
v3 (LLVM Back-end)
The LLVM back-end is not self hosted however I may use it to recompile v2 because:
a) I demonstrated that V1 can compile V2 b) I demonstrated that V2 can compile V2 c) The issues surrounding a v3 from a v2 are memory management issues and: d) They could be solved by reworking the memory map but I don't want to do that yet because I want to do it for a v2 kernal rewrite.
Here's the thing
v1, v2, and v3 are not intended to be frestanding in the sense that they use INT 0x10 for putchar and getchar. However, what this all amounts to is a chicken and egg rewrite TinyC v1 and the Kernal at the same time, and although I am superhuman I am not ultra-superhuman. Its a death by 1000 cuts. The 1000 cuts are all multiplicative and it got to the point where going through the living hell of writing an LLVM backend (6+ months of work) is visibly cheaper than doing it completely self hosted from scratch.
I just wanted to try it with LLVM I guess. I tell myself in consolation, if v2 can compile v2, then it would only have been a matter of time before a v3 could compile a v4. Doing a full-freestanding LLVM backend for the SD-8516 just kills all five birds with one stone. A very heavy stone. I tell myself, it's fair, because either way it is a living hell of epic proportions to get this all done. The LLVM way, is just easier to conceptualize. it makes the black box “one thing”– get the LLVM backend up. Then the top-down design plan can continue.
- Get the LLVM backend up.
- rewire the memory map to put the kernal in bank 0
- …as we rewrite the kernal in C
This all needs to be done anyways because carts will need to be freestanding and not dependant on an upgradable OS. Like a console. The SNES doesn't have a command line or a MON or a programmer's interface. Moving the kernal to $0 and video to $1 means we can use everything else in one solid block which is just how I like to think.
The big issue
The big issue now is how to package it for other people to use.
Currently if you want to write C for the SD-8516.. frankly, write your program and send it to me and I'll compile it for you. Trust me when I say that is easier.
Packaging it simply will take too much time away from developing it.