Thread with 9 posts
jump to expanded post
these last few weeks, @lynn and me have been working on a c compiler for uxn, based on rui ueyama's “chibicc”. it's been a lot of fun! it's such a cute little vm… assembly for this tiny stack machine involved so many little puzzles.
i made a demo https://github.com/lynn/chibicc/blob/uxn/examples/star.c :3
there are a number of important limitations, but it's already usable enough to write small games and demos. with some effort, it's even possible to port some existing software! i've managed to get a certain classic app working in it. i'm hoping to announce it soon :3
the fact it's a stack machine makes it really fun to write (or generate!) assembly for. you never have to remember register numbers, all the inputs and outputs are implicit. the magic of concatenative programming~
one of the challenges was that uxn doesn't have signed integer operations, but they're essential for c code, so i had to write some little helper routines that emulate signed operations. for example, this does sign extension (char->int conversion):
#80 ANDk EQU #ff MUL SWPthe single most complicated thing to emulate was, believe it or not, argc and argv: https://github.com/lynn/chibicc/blob/uxn/routines/argc_argv.tal
don't let that scare you though, most of the compiler isn't anywhere near that complex, hehe
writing c code with this compiler also involves a lot of problem solving. there's no floats, no 32-bit integers, almost no C runtime, and only 64KiB of ROM space. the compiler can't do much optimisation of your code. you'll have to be creative!
related: https://social.noyu.me/@hikari/statuses/01H2G44V6QJ7BB9Y3J25QCEPB8
@cr1901 @lynn i can't really speak for lynn but i think the feeling is that we'd rather not have something requiring such heavy runtime support. it's not something most applications need, you should only use it sparingly, and you can just call it via asm, or maybe via improved extern support in the future