A little C compiler https://git.lemon.rip/antcc/atom?h=trunk 2026-03-17T12:22:00+00:00 2026-03-17T12:22:00+00:00 lemon lsof@mailbox.org 2026-03-17T12:22:00+00:00 urn:sha1:a8d6f8bf30c07edb775e56889f568ca20240bedf 2025-12-15T21:39:52+00:00 lemon lsof@mailbox.org 2025-12-15T21:39:52+00:00 urn:sha1:302e24671942051d70707586cf8c605a5815edac Interned strings are used pervasively, so it's a good idea to add a layer of type safety to differentiate them from general cstrs and avoid potential bugs from comparing non-interned and interned strings. Not that that's happened so far that I can remember, but it could. I'm 90% sure it's legal to alias `struct {char c;}` pointers with `char` pointers. This specific typedef gives type safety but with a simple one-way `internstr -> const char *` typecast (with `&istr->c`). Converting the other way around is more intentional: a straight up cast `(internstr)cstr` which sticks out as unchecked and probably wrong, or calling the intern(cstr) function, which is the right way. 2025-12-14T11:15:59+00:00 lemon lsof@mailbox.org 2025-12-14T11:15:59+00:00 urn:sha1:d8b4e87af669c2b260686a5db67f7f02b4c164d9 With 59ca5a8db, querying if a symbol is defined is cheap. If we're compiling code that calls foo() and we defined foo() in this compilation unit, we already know its offset within the .text section, so use it instead of emitting a relocation for the linker to handle. Also, put small literal data in the .text section instead of .rodata. This seems to improve performance (cache locality?), and as a bonus, it will be good for aarch64's instr encoding with smallish PC-relative offsets. 2025-12-02T13:21:59+00:00 lemon lsof@mailbox.org 2025-12-01T18:10:53+00:00 urn:sha1:c14321c4d35549d989d614437953b36b8c771cc2 2025-10-19T06:09:09+00:00 lemon lsof@mailbox.org 2025-10-19T06:09:09+00:00 urn:sha1:dea8fd171acb54b6d9685422d5e391fb55074008