Differences

This shows you the differences between two versions of the page.

--- sd:programming_in_c_for_the_sd-8516 [2026/06/17 10:02] – appledog
+++ sd:programming_in_c_for_the_sd-8516 [2026/06/17 12:24] (current) – appledog
@@ Line 26: / Line 26: @@
 == Self Hosted TinyC v2
-v2 is v1 written in C. It compiles but there are issues I am working on.
+v2 is v1 written in C. It compiles but there are issues. The issues revolve around the fact that this type of computer system is not really intended to host and run a C compiler. It can be done but as I have learned, the easy way forward is to rewrite the memory map and the kernal. This creates a chicken and egg problem. I need to rewrite the kernal, but I don't feel the need to rewrite the kernal in C just to rewrite the C compiler.
 == v3 (LLVM Back-end)
-The LLVM back-end is not self hosted however I may use it to recompile v2 because:
+The LLVM back-end is not self hosted, obviously. However, I am learning a lot about C by doing this and I may be able to use what I know to help write v4 under the v2 compiler. Or at least, write v4 in v3 then try to back-work v1/v2 to compile that. Either way, this is the path forward.
-a) I demonstrated that V1 can compile V2
+== What about right now?
-b) I demonstrated that V2 can compile V2
+Given all this I recommend you program in assembly first. That's really what this project is about, the retro way. You should give it a shot, if you've never tried assembly before. This platform is designed with hand-assembly in mind. Like the old days.
-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
+However, if you really want to program in C, well, talk to me, and maybe we can work something out where I try to package this for you to test it out.
-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.