Differences

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

--- sd:tinyc_developer_diary [2026/04/19 09:09] – appledog
+++ sd:tinyc_developer_diary [2026/04/22 17:14] (current) – appledog
@@ Line 808: / Line 808: @@
 </codify>
-== Digging a very deep hole
-This isn't working. I have to increase the number of symbols. If this doesn't work I should just re-write the symbol table.
-Every place which touches the symbol table has to be word sized not byte sized. This is the pattern:
+== A classic clobbering bug
+To do forward declarations, the code used two special global variables to pass information between two parts of the code: KIND and ENTRY. KIND told the code whether the function was already defined (kind 2) or just forward-declared (kind 4). But the same part of the parser that identified a function was being recursively called on the arguments of that function. So during the parsing of the arguments the function type was being over-written. And therefore it's address was not being back-patched in the patch loop chain.
-    cc_sym_clear:
+Now I know this sounds simple when I lay it out, but this took me 10 hours to fix. It's just a classic clobber-bug but it's a sign this code is starting to weigh me down. I just want to write some games. I don't understand why this has to be so hard. But even after all this I am pretty sure it is easier than writing a GCC or LLVM back end.
-        LDA #0
-        STA [@CC_SYM_COUNT]
-        RET
-... for every _sym function. And any time CC_SYM_COUNT or CC_SYM_SCOPE is used.
+== Everything in bank 0!
+I was such a fool to make the symbol table 16 bit. Now everything has to be in bank 0. But there's not enough space for self-hosting. The code AND the compiled code both are over 32k.
+I have a plan. What if we put the output ~2k before the source code? The tokenizer and other things seem to output less bytes than source code, so it should work.
+So if HERE grows into the source area as source gets consumed, we can theoretically use up to 48KB for source code AND compiled code. This requires HERE to stay behind SRC at all times. It destroys the code as it compiles, but that's okay. The two pointers march through the memory, with HERE chasing SRC. The only problem is if the emitter somehow catches up with the source code pointer.
+At this point I am very close to just rewriting the symbol table to be 32 bit. I mean this is already an insane asylum as it is, but, how hard could rewriting the emitters possibly be? :)
+== Rewriting the symbol table
+Unfortunately the symbol table had to be rewritten and all the emitters. This is not as bad as it sounds but it required a complete review. The good thing is I had a register map, where I used certain registers for certain things as a convention, or this would have been impossible. I will be sure to mention register conventions/register maps in an upcoming tutorial.
+. In every place where the symbol table was written or read, make sure a pointer (GLK) is used. Previously, A was used for this. This wasn't too bad because sym is a marker for symbol table functions.
+. In parse function, emit_call, anything to do with backpatching, etc. we need to make sure we are using a three byte value.
+. Anything which touches HERE or offset 18 of the symbol table. This is an easy search for ex. LDA [@HERE].
+It took a couple of hours. As I ran through various tests it struck me that there are a series of tests I went through a couple of times before to verify things work. As I ran through them again I had the insight to write them down.
+=== TinyC Test programs
+These provide the test cases I used to check my compiler. In order.
+==== First
+<code>
+int main(void) { return 0; }
+</code>
+==== Symbol table
+<code>
+int main(void) { int a = 5; return a; }
+</code>
+bit:
+<code>
+.clear
+int main(void) {
+    int a = 0x123456;
+    return a;
+}
+.compile
+.run
+</code>
+==== Globals
+We can't define them when we make them. It seems like I did something wrong here but I don't know how to fix it. Just define them in main. Whoop de doo.
+<code>
+int g;
+int main(void) {
+    g = 42;
+    return g;
+}
+</code>
+==== function call
+<code>
+int a(int x) { return x + 1; }
+int main(void) { return a(41); }
+</code>
+two arguments:
+<code>
+.clear
+int add(int a, int b) { return a + b; }
+int main(void) { return add(20, 22); }
+.compile
+.run
+</code>
+==== Forward Declarations
+Single
+<code>
+int a(int x);
+int main(void) { return a(41); }
+int helper(int x) { return x + 1; }
+</code>
+multiple
+<code>
+int a();
+int main(void) {
+    return a() + a();
+}
+int a() { return 5; }
+</code>
+==== Recursion
+<code>
+int even(int n);
+int odd(int n);
+int even(int n) { if (n == 0) { return 1; } return odd(n - 1); }
+int odd(int n) { if (n == 0) { return 0; } return even(n - 1); }
+int main(void) { return even(10); }
+</code>
+==== Built-in functions
+<code>
+int main(void) {
+    putchar('h');
+    putchar('i');
+    return 0;
+}
+</code>
+=== Re-wiring pointers
+Unfortunately the changes were far more in depth than I expected, and I had to spend an additional ten hours going over the code to fix pointers, the lexer, and everything in between. Oh, and yet more emitters I forgot needed to be changed. Even the REPL itself didn't print out the full return value. This makes me reconsider my choice to go with a 16 bit system. Should the SD-8516 have been 32 bit? Maybe, maybe not. In the end, it works. A 16 bit system can run a 32 bit c, no problem. I mean, look at Commodore BASIC 2.0. It used floats for ints. Steve Wozniak even made a Sweet-16 so that it could use 16 bit registers. We can do 32 bit in the languages. No problem. We are not going to get any practical advantage from going 32 bit internal since we're running on WASM which is 64 bit native anyways. See? We can have our cake and eat it too here.