all i have left is builtins. i keep wanting to tackle imports for 1.0 but like, it's not necessary, all the code could go in one module to avoid that support.
#minidragon
okay i got peek() and poke() working for all supported data types, and also did a quick swap out of one internal memcpy unrolled implementation to another which netted me an automatic few cycles win here and there due to how the second implementation works.
alright well shift expressions are now fully supported against all supported integer types and with static or expression-based shift amounts.
the TODO list is down to 2 items for a 1.0 release.
things that i will probably want to add/work on after 1.0 include:
- import statement support. right now you can just write everything in one big file, but yuck. no encapsulation, everything public. imports would be easy because the compiler would just load and parse out forward refs in the other file and the assembler/linker would work out as it currently does.
- desugaring truthy expressions. once i implement the above builtins, you'd be able to do if bool(string): to run code if a string is non-empty. but it's more pythonic to just if string: instead. i can desugar that by inserting a virtual bool() call when necessary.
- start tackling optimizations that i've ignored for now. there's a lot of them. i think that with some weeks focused on optimizing the output a lot of codegen could be made much better and faster. both speed and space are at a premium on this thing.
things on the (ever shortening) list of necessities for the compiler to reach what i'd consider a 1.0 are as follows:
- << and >> expressions. i forgor them and my CPU doesn't have the ability to shift by variable amounts, so i gotta figure out if i want to support shifting by expressions or only constants.
- couple of builtins that make casting and working with things possible: abs(), bool(), chr(), ord(), int(), hex(), min(), max()
- implement a peek() and poke() builtin. i'm skipping on pointers and integer/boolean arrays for the time being, meaning it won't be possible to describe raw memory access in the language. right now you can only reference global labels in the assembly or stuff on the stack. peek() and poke() would fix that.
with those three bullet points, i'll call 1.0 finished.
well hot damn, my compiler supports python f-strings.
okay, that's that. str() works. i can now convert from any type my compiler supports to a string. in the process i ended up finding all sorts of little edge cases here and there that were wrong in the compiler and fixing all of those up. i'm exhausted so no more working on this tonight, but tomorrow or friday, it's time to implement f-strings! i'm going to implement it by just desugaring it into a bunch of string concatenations and casts under the hood which should be fine, but it will work!
yeah okay i'm already done with the additional functions AND the tests. that was easy. gonna be a much longer road to write the compiler bits to call these functions...
fixed the compiler bugs with globals that i punted on last night and am now in the process of working on str() where i'm realizing my stdlib itoa is just that, integer to ascii, not unsigned integer to ascii. meaning while my atoi implementations can cope with negative numbers or unsigned numbers, my itoa cannot. so i can't reasonably convert unsigned numbers. ugh, sounds like i'll end up needing unsigned variants of those...
initial tests are looking good. thought about testing another weird edge case unrelated to what i implemented tonight and would you look at that it doesn't work. fixed one bit of why it wasn't working and now it executes but gives the wrong result.
but i'm out of steam for the night and don't want to keep going. so debugging this and finishing up the rest of the tests will have to be a tomorrow thing. i'm gonna augment a bunch of other string tests to verify this edge case in those tests too once i get to it.
but tonight: be a lazy, stinky dragon.
i literally need to support string[x] = 'c' and i'm done with the basics. wow~
oops, added in a check in the assembler for duplicate labels i should have added a loooong time ago and uncovered an issue with duplicate local string allocations on the heap when initializing a string from within a control flow branch.
just about finished with validating for character concatenation on the end of a string. fun thing, i can use it to write a terrible strcpy and it works :3
okay well if i go with this, i can decode the address space using a 74HCT00 and a 74HCT30 to generate the ROM/IO/RAM enable signals, and then use a 74HCT138 to split the 2K of IO space into 8 256-byte segments for 8 different IO expansion cards. that's not bad at all. each IO card only getting 256 bytes of address space means i only have to route the low byte of the address bus to each card, cutting down on the number of signals on each connector.
each IO expansion card would end up getting a !CS (chip select invert) signal, a !WE (write enable invert) signal, a !RE (read enable invert) signal, !RST (reset inverted) signal, CLK (system clock) signal, 8 bidirectional data lines and 8 address lines. so 21 signals in total per card. plus VCC and GND. so could be routed to a 24 pin card edge connector which is relatively small. nice.
messing with the memory map again for the minidragon and i think i'm going to size down the IO memory mapped space to the upper 2KB of the ROM instead of the upper 16K. that means i can take advantage of almost the full ROM space instead of banking it, and the chips i have planned for the IO space won't notice a thing because none of them require more than 2 address lines.
i'm hoping to have f-string support in the compiler by friday, but i don't want to set a strict deadline for myself because i shouldn't be stressing over hobbies
i forgor to post about it while i was doing it but i got string comparisons working (mapped to existing stdlib function strcmp and tied into the codegen that already used the result of cmp/ucmp for integers) as well as some more stuff for characters worked out and character comparisons working as well.
i keep inching closer to claiming success with string support :3
okay, rewrote the codegen that was previously simply advancing the string pointer forward by the beginning slice amount to take into account checking for null termination bytes and all of the test cases now pass~
i think i'm done with implementing anything else tonight.
spent the evening trying to figure out why my string slice code wasn't working and always acted like the passed in value was zero. ended up augmenting the CPU emulator core to be capable of highlighting changed RAM bytes and registers between instructions to help trace code. ended up being an optimization for relocating the return value, assuming that expressions would never write back to the destination until fully calculated. that's wrong for non-constant strings which are actually pointers, which get written to when the string is initialized by pointing them at function-local RAM.
so, updated the function that determines if the return relocation optimization can be applied to exempt string returns with function parameters in the same spot, and now it's working. just gotta tackle the memory safety edge case now. i wrote tests to verify it and as expected it fails those edge cases. onward to the fix!
note that all i have to do is advance the start pointer for slices that have a non-zero start index one at a time and verify that i don't hit the null termination byte. that's it. everything else is handled by strcpy/strncpy. but i'm lazy lmao.
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst