social.noyu.me

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 SWP

the 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

btw, uxn/varvara is a really impressive vm. what amazes me is how small it manages to keep its api surface while still providing everything you could want: graphics, sound, mouse input, keyboard input, gamepad input, file i/o, a real-time clock, stdin, stdout and stderr!

it does all of that while having far fewer api entrypoints than posix or wasi or the browser or any api you can think of, and they're all defined in such simple and constrained ways that there's very little room for incorrect implementations (though still some: i have found bugs)

so i think uxn apps will have fantastic portability. better even than famicom roms, and yet they can do more!

it'll never replace wasm: apps can only use 16-bit integers, a 64KiB address space and 2-bit color. but that's still a whole universe of creative potential. i love it.

the limits aren't without advantages: it's a universe where you can store your whole app collection on a floppy disk, or run it on a gba…

i am pleased to announce oneko-uxn: a port of oneko-sakura to #uxn. this is a version of the classic software ”Neko”! 🐈🖱

https://github.com/hikari-no-yume/oneko-uxn

日本語版も有ります。

this all was made possible with chibicc-uxn, the c compiler for uxn that @lynn and i have worked on together.

have fun!

i painstakingly preserved the structure, comments, and feature set to the greatest extent possible… parts of this codebase are several years older than i am, and i wanted to respect the history. it's the most faithful port of this program that is possible, i think!

i found a bug in oneko-uxn: the 16-bit Euclidean distance calculation can overflow even for 8-bit inputs :(

but @lynn found a great alternative: the average of the L1 norm and L∞ norms is within ~6% of the Euclidean distance, and way easier to compute!

https://github.com/hikari-no-yume/oneko-uxn/commit/060bc664e647e3ea6d1362fa5d882c1d1b95a87c

@hikari @lynn What's the red curve represent?

@cr1901 @lynn

0 ≤ x ≤ 2π

cx = cos(x)
sx = sin(x)

i plot a point at (cx, sx)

interpreting (cx, sx) as a vector from (0, 0), the euclidean distance is always going to be 1, right

i then calculate the same distance with our approximation, and plot a point at (cx * distance, sx * distance)

so the red line shows how far it strays from euclidean distance at various angles