Differences

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

--- sd:programming_in_c_for_the_sd-8516 [2026/06/17 10:17] – 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.
-=== The big issue
-...Aaaaand, I can't make them totally freestanding without changing the memory mapped input anyways. So basically the whole thing is dead in the water and the entire project needs a total rewrite.
-Doing a full-freestanding LLVM backend for the SD-8516 kills //all// birds with one stone. A very heavy stone. Whether I redesign the memory mapped system and kernal or do it this way first, 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.
-I guess what makes me sad is I wrote this whole thing in assembly and now that I want to bring up C, C itself is bucking the retro nature of what I am doing. C itself is telling me, "be more like UNIX and less like a C64 or Apple II". As it turns out, C itself is a really different paradigm than the old ideas behind a hand-assembled BASIC interpreter. Systems build around that are just //different// and not well-suited for C. Bringing C up almost requires your entire system be written in C anyways. It starts to infect and change every little thing about your system. I don't know if I really even want that kind of change. I like my system. I didn't plan on all these concessions for a C. Most of what I have been doing, actually, is adding things to my assembler and CPU core to support C and the LLVM back-end. It was working fine before.
-But before, we didn't have a C.
-It seems, C is not just a language, but an expression of a computer architecture. And as such it is hard to bring it up  on an architecture which is dis-similar to the one it was designed on. This may mean C is not the best language for the SD-8516. Like a square peg in a round hole.
-And yet I soldier on. My mission will be to retain as much of the freespirit of the SD-8516 and conform to C as little as possible while getting a full self-hosted C. I do not even know if this is possible, but I am about to find out!
-=== The plan
-# 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.
-Or maybe put the kernal and the video at the end of memory.
-=== So, LLVM is the solution?
-Basically I want to use LLVM to freestand the entire system in C. Then that becomes the rewrite. I think that's valid. Maybe what I should do is actualy change away from a memory mapped system to special CPU opcodes that access devices. Maybe INT needs to poll for IO instead. I don't know.
-I just got this conclusion that the memory map is what is gumming up the whole system and I need time to think. Nothing can get done until I think this through. So getting a back-end up in LLVM will give me time to think.
-== The other 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.
-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. If you really want to program in C, well, it's coming, but C was never really common on the early home computers. They were more BASIC/assembly.
-Anyways, i'm working on it, i'll post what information and updates I can..