#pldev — Public Fediverse posts

so since i feel compelled to work on Bismuth again and my bright idea is that i should bootstrap the bytecode compiler, the big question becomes:

what kind of language is best suited to writing a bytecode compiler? 🤔

please weigh in #PLDev folks, i need your wisdom

I’m at a point where my language (https://arkscript-lang.dev) is usable for scripting, is on a code golf website, has a decent documentation, a growing stdlib, decent performances, and yet…
I don’t know where to go from there
Package manager? Not enough users, no real need
Bigger stdlib? What should I add then?
More docs? Maybe, but from my pov it’s hard to know on what I should write
More optimisations? Probably, this couldn’t hurt, now that I have an IR inliner and optimiser

I’m open to suggestions, I’m a bit lost right now

#ArkScript #langdev #pldev

It's been a while since I posted about the development of my scripting language with Rust-like syntax - the reason being that I got stuck on the handling of `use` statements and cyclic dependencies between modules a year ago

I finally got unstuck and have a working implementation now, but I also did some work on error reporting to get back into the code base :3

(and what I am even building this for will be revealed at a later time ^^)

#PLdev

Just stumbled upon [1] a thing called "assertion based slicing" which allows you to slice something like

fn f(x, y) {
x += 1
y += 1
x - y
}

into

fn f(x, y) {
x - y
}

by introducing pre & postconditions between statements and removing any statements where the relevant part of the postcondition is already in the precondition. Witchcraft.

[1] https://doi.org/10.1145/3764581

#compiler #PLdev

I also have messed up the VM stack, probably because removing a CALL instruction is a bit more involved and you need to remove the associated PUSH_RETURN_ADDRESS (first, push the addr, then the function, its arguments, and finally call it ; that way the stack is correctly setup once you hit a RET instruction and we know where to go back to)

Seems like it’s more complicated than that, even if I avoid using LOAD by index instructions, because the stack is still broken.

The inliner itself is very dumb: remove the CALL and replace it with the function body (minus the RET instruction). Of course this overwrite variables, but I can fix that later.

I must be missing/forgetting an important piece of information about how the VM expects a CALL to go…

Until we meet again!
#pldev #ArkScript #langdev

I've finally started work on an IR inliner for #ArkScript, and so far, I think I have found a decent heuristic (that **will** get tweaked once everything is in place)!

Inline only
- non recursive functions,
- simple functions (calling only builtins and operators, no other functions),
- non closure functions,
- functions that don't instantiate closures,
- functions with a relatively low instruction count (arbitrarily chosen to be 24, for now)

Except for some load symbol/load symbol by index shenanigans, I don't see what could go wrong

#PLdev #langdev

What would a good replacement for the C language look like?

Assuming that for whatever reason Rust ain't it

#PLDev #programming

I think programming languages have a tension between people trying to learn the language going "what the hell do these hieroglyphics mean, use keywords!" and people who know the language going "I just want to type less, let me use punctuation instead of words!"

#PLdev #programming

I messed up a few years ago when adding list:find and similar functions to my language, #ArkScript
The language has a void value, nil, but those functions return -1 (as in C...)
Alas -1 is also a valid index in ArkScript (same as Python)

I'm unsure about how to change that

The deprecate and change the type in the next release option seems "decent", but I feel like it's abusing deprecation warnings

#pldev #langdev

I built an esoteric programming language: https://rphle.de/tzap/
It only has 4 instructions and no arbitrary values like numbers or memory addresses.
I challenge you to implement Fibonacci in it!

#esolang #pldev #programming #programminglanguages #challenge

The latest iteration of number_loops() which is giving me encouraging results, at least on the test case scribbled above...

#Projects #Compiler #PLdev

A visual aid while debugging code to identify backward branches, number loops, etc...

#Projects #Compiler #PLdev

The graphs generated by iongraph (a Mozilla tool for SpiderMonkey) are a lot nicer than just trying to wrangle reasonable outputs from graphviz:
https://github.com/mozilla-spidermonkey/iongraph

Nice writeup about the layout algorithm here:
https://spidermonkey.dev/blog/2025/10/28/iongraph-web.html

Strong temptation to build some custom graph generation tooling for my own language hackery. Looking at lightweight PDF generation libraries.

#PLdev #Projects #Compiler

Anyone know of any good writeups out there on the reverse linear scan register allocation (on SSA form IR).

I'm especially interested in discussion of register usage hints or constraints around things like calling conventions -- landing parameters in the right registers, but making the most of those registers outside of call boundaries, etc.

#PLdev #Questions

Implemented the RV32I pass-by-register calling convention in the simple SR32 code generator... as a compiler parameter.

Updated the emulator to support either calling convention (at runtime) for syscalls.

This all works, which is nice, but now I've just added a third dimension to the test grid, which is less nice.

#Projects #Compiler #PLdev

The desire to explore Subnautica 2 (now in early access) is warring with the desire to generate assembly from IR now that register allocation is happening.

#PLdev #Gaming #Argh

Rearranged the register assignments in my softrisc32 ISA to match that of RV32I because there's no point in maintaining a variant register map just because I find the RV32I map "untidy" (due to them arranging stuff to make sense when the top half are missing in RV32E).

This has the side-effect of making (textual) sr32 assembly even closer to rv32i assembly.

About to shift from passing parameters on the stack to passing parameters in registers.

#Projects #Compiler #PLdev

Starting to allocate some registers. I need more test cases with greater register pressure. Most of them fit within 4 working registers just fine.

I did update my live range graph in the IR dump to use dashed lines for spilled registers.

Here's one that spills at 4 and spills a bit more at 3.

#Projects #Compiler #PLdev

Housekeeping to allow the -out path (for final compilation) and the -xir path (for eXecutable IR useful for validation) to coexist in a single compiler invocation. Also some tidying up of argument wrangling, improving the XIR format so writing it is non-destructive (to allow generating pre/post optimization variants), tidying up output file argument handling in main, and separate flags for dumping ir0 (initial IR generated from the AST) and -ir1 (final IR).

#Projects #Compiler #PLdev

Next: Finish up register allocation and selection and final code generation from the IR. At which point it should be self-hosting through the full stage3 compiler. Guessing it'll wind up around 8000 lines of code total once that's done, but we shall see!

Not tiny, but not enormous either.

#Projects #Compiler #PLdev

Cleaning up the validated AST form involved having the AST be more consistent about types, in particular pointers (which are generally not explicit in the language syntax, except when indicating if a struct field that is an array or struct is inline or not).

This resulted in an explosion of Type objects (2438 total, 1978 of them pointer-to-x types) when building the compiler.

Adding a pointer-to cache field in Type dropped that to 580 total. ~76% savings.

#Projects #Compiler #PLdev

That took a few days to get sorted, and it's not entirely done until I fix up the stage3 compiler's IR generation to work with the revised AST that the validation phase now generates, but stage1 and stage2 pass all tests and the a bunch of weird quirks from the early days of the project have been sorted out.

Responsibility for validating types, handling lhs vs rhs differences, managing other bookkeeping now lives entirely in the validator.

https://github.com/swetland/spl/commit/0f2f73521ea9ef55e9a6b57ae204b763bdf519a3

#Projects #Compiler #PLdev

Needing to better formalize the rules for pointers (which only exist explicitly in structure or array type definitions to indicate if fields or elements are in-line or not) to make sure the implicit dereferencing (or not) happens correctly. Getting closer. Doing it post-parsing but pre-codegen is definitely feeling better than the original side-effect-of-codegen approach that got really messy.

Only a couple tests not passing with all these changes.

#Projects #Compiler #PLdev

Putting the sr32 code generator back together around the new AST nodes the post-parser validation step generates/transforms, hoping that the result will indeed be simpler, cleaner, easier to follow, and worth the big mess I made tearing everything apart.

#Projects #Compiler #PLdev

I'm conflicted about how I should implement UTF8 support for strings in my language, #ArkScript

There seem to be two options:
1. Every string is UTF8, thus every access to a char is O(n) and not O(1) anymore (have to decode the codepoints to count them). Length is O(n) too. That pretty much pessimizes all strings, even ASCII ones, but makes working with UTF8 codepoints easier
2. Every string is just a series of bytes, as it is right now, and a (@ string index) returns a potentially invalid character (on 8 bits). Indexing and length are O(1), but we need a function to get the codepoints, like (string:codepoints str) or (string:graphemes str) or something else
3. third hidden option that I want to avoid and that doesn't really count: introduce another string type that's different from normal strings. That's bad because the C++ API will be impacted, and the internals will need to handle all the different string types

At first, I thought option 1 was better because then everything is easy, since the language is high-level. But now I lean toward option 2 because UTF8 support won't hinder the performance of programs that don't need it, and doing such a thing should be intentional

#pldev

You might remember that I was working on my own programming language a few months ago. I've decided to write a blog post about what this language is, how it is implemented, and what are my future plans!

#programming #pldev #compiler #arm64

https://lisyarus.github.io/blog/posts/making-your-own-programming-language.html