Frame – Linux X server in Assembly(isene.org) |
Frame – Linux X server in Assembly(isene.org) |
If someone had written this program manually, the strategy would have been very different. With a good macro-assembler (and nasm is good enough) one should define a great number of macros, to encapsulate all the tedious boilerplate, especially for things like function prologues, epilogues and invocations.
With a well written macro library, an assembly program can be almost as compact as a C program, instead of containing many text lines for each equivalent high-level language statement.
Such an assembly source with good macros can be read and understood much more easily than raw assembly language, like in this "frame.asm".
Otherwise, this is interesting work.
The other day, colleague showed me a (pretty basic) terminal emulator written in one-shot by Opus. Kicker is - that was compiled to a 30 KB static binary. That's right. No libX11, no libXfont, not even libc.
On a long enough time frame with enough tokens invested there’s probably not a difference, but being written in assembly by an LLM doesn’t imply optimal to me. I’d almost prefer having an LLM rely on higher level abstractions offered by a programming language rather than rolling everything itself. After reviewing a lot of LLM code, even at Fable and Sol levels, I just don’t trust that LLMs are writing optimal code. Assembly makes it harder to even review.
I do it find it very fun and entertaining. This is a component and I’m grateful that it was shared.
Writing maintainable assembly is at odds with writing fast assembly in most circumstances.
A key optimization that's hard to pull off is inlining.
An optimizing compiler can see that a method is small enough that it can be pulled into the caller, it can then further eliminate from that smaller method branches that can't be executed due to the nature of the caller (Imagine calling a function with a `bool` parameter and you send in `true` at the call site).
To make the code faster in hand written assembly, you have to do the inlining, but that makes writing more structured code a lot harder. You are duplicating logic paths in the name of performance.
Not to mention the fact that the compiler gets updated and knows about more instructions and architectures then you do or then you could have. Hard to write the FMA instruction if it didn't exist when you were writing the assembly in the first place.
That entire point is moot here because the abstraction in this case is a massive ball of crap and it's used everywhere. So you never get the benefit you think you would for using a lower level language. That's why generally LLMs are best with python and even better with a "harness" (domain specific framework and language)
I see the growing trend of words losing all meaning is still going strong in 2026. I wonder what human communication will look like in the near future?
Also, has anyone run it successfully? I got as far as building and running with --display and then running `DISPLAY=:7 dwm` and `DISPLAY=:7 alacritty`, but I can't seem to focus the window to actually type. Given that the author posted a picture of the thing actually running a live environment and claims to actually be using it, I'm pretty sure this is a me problem but I haven't been able to figure out where it is. Mouse works, too.
Isene and I have relatively similar philosophies on this, except I have Claude burning tokens on optimizing and fixing my Ruby compiler now because I still want things in a high-level language, and my entire stack is Ruby instead of asm. But I love what he's doing - I just don't love x86 asm...
Turns out a functioning X server is a relatively simple piece of software. It's mostly just tedious. And most of the bulk is protocol handling that Claude can handle really trivially.
by claude code. So this was only possible since no human had to bear looking at X original source code.
Working: tile, dwm, pcmanfm-qt, feh, dmenu, glass
Not: alacritty, st
So... Thus far, anything but a terminal other than glass. I'd think the problem was alacritty doing fancy things with APIs that frame doesn't have, but st??
I suspect (with zero proof or understanding) that this has something to do with how well C maps to assembly. It's not a stretch to say the model's vector space maps this chunk of assembly with that line of C. And we all know how much C code exists online.
(Oh, and the "compiler" will also refuse to generate certain types of programs.)
I've had all my side projects being written in x64 for the last 6 months and it is shockingly effective.
Or:
$ objdump --disassemble /usr/lib/xorg/Xorg
No dependencies and better performance? Fantastic.
COBOL and 4 GL dreams coming into reality.
Working on it:
https://github.com/X11Libre/xserver
And they also deleted old code too. A lot of the old code could probably be removed, but is it really that relevant whether you have 4 millions line of code or 2 million lines of code? C is in my opinion too overbose. Rust is even worse. Which language would yield fewer lines of code without speed penalty? C is king largely because of the speed gains. We don't see people use python for an xserver.
recently i also rewrite most of the app's underlying core function to rust, just like the guy do for the phone
perhaps i should also do more stuffs given codex reset too quickly
A Dockbar I am working on https://github.com/edumucelli/docking/ is a pain to build on Wayland. It already supports a lot of composers and even mutter/gnome with that Gnome shell extension, but at what cost ...
You can always use XWayland if you feel that way.
So you can't really "fix it", short of patching e. g. Gnome's compositor, with patches that will never be accepted upstream.
I wish mine had no fan too except me.
AI wrote*
I've never quite found that Linux is more optimized on battery-powered machines for energy savings, even though supposedly there is a lot of room to tweak and optimize settings -- from selecting a low resource window manager/DE to turning off various services to switching up power management utilities. But this does seem like an approach that might produce that kind of fruit?
Also disable hardware SMT as a kernel option in grub config. Then the cores can clock down way more often and L1 data cache size doubles.
XFCE and X11 tripled my laptop battery life vs. whatever Wayland+GNOME Ubuntu (2024?) brought by itself.
Powertop and tlp also help.
Happy camping.
EDIT: the lower heat dissipation also halved boot time. That one surpised me the most.
EDIT2: Disable "atime" with ext4 option "noatime". Saves a lot of power, heat, trimming, and re-writes on your SSD/NVMe.
For "faster shutdowns" manually run systemctl start fstrim.service. Not exactly sure why fstrim.timer seems unreliable.
For example, I recently got another 1 hour out of my old laptop's battery because I didn't realize for the intel video card driver I needed to add some modprobe flags to get it to load up a firmware binary blob. Doing that enabled hardware video decoding, faster performance, and lower power usage.
There's a bunch of setting like this that you need to make sure are turned on to get the best battery performance. Some OSes are better about toggling them than others and mine (gentoo) let's you discover later that you forgot to turn them on :).
Many distros already try to push good defaults, but you can do a whole lot when optimizing for a mobile experience. You can also do some fun stuff with it, like running a script[1] when going from ac->bat power to, e.g., turn of a service, lower refresh rate or reduce brightness.
[0]: https://linrunner.de/tlp/index.html [1]: https://linrunner.de/tlp/usage/run-on.html#run-on-ac-run-on-...
Have you ever compiled something by hand? You should try sometime, it's an illuminating experience. Humans find it hard because you have to remember a lot of details while simultaneously paying attention to a different large set of information while also generating instructions. It's tough, but not impossible, it takes humans a lot of time and effort. How might a computer fare if it could remember everything and pay attention to multiple inputs and outputs at once? That's what an LLM does.
static inline long read(int fd, void *buf, long count) {
register long rax asm("rax") = __NR_read;
register long rdi asm("rdi") = (long)fd;
register long rsi asm("rsi") = (long)buf;
register long rdx asm("rdx") = count;
asm volatile(
"syscall"
: "+r"(rax)
: "r"(rdi), "r"(rsi), "r"(rdx)
: "rcx", "r11", "memory"
);
return rax;
}In my memory the syscall ABI has changed a few times (i386 had int $0x80, then sysenter, then abstracting it in the vdso, then amd64 has 'syscall'), so it may be easier to let the kernel header provide the mechanism.
The machine I'm typing on is the 2nd newest in the fleet -- it's a work box -- and it's an i7-8550U, an 8th gen "Kaby Lake" chip.