Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Frame – Linux X server in Assembly

isene.org

Post reply on HN
Print view View original

81–90 of 115 posts

Re: Frame – Linux X server in Assembly

#81

Post by yjftsjthsd-h »

asveikau wrote: post #67
kees99 wrote: post #40

Earlier quoted context omitted.

Yes, something like this: 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; }

The linux kernel also has its own headers (IIRC it was something like and/or , but might depend on architecture and version) where it will provide the stub asm statements. 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 Linux syscall ABI is (famously) stable; on x86* you can still call into 0x80 just fine. There might be new interfaces made available, but existing programs shouldn't break. Although, in C there could be value in abstracting over the per-platform differences like int/syscall. I've only ever done raw syscalls from assembly where portability was rather moot:)

Re: Frame – Linux X server in Assembly

#82

Post by vidarh »

vitally3643 wrote: post #68
ToyKeeper wrote: post #13

It's funny to see someone using a LLM as a compiler, making it convert higher-level operations into assembly, instead of just using a compiler.

Given how few programmers very seriously write lots of assembly, it's kind of astonishing how good LLMs are at working with assembly. They can compile and decompile all on their own with apparently very little effort. 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…

It's relatively recent, I feel. Claude used to really struggle with writing asm not that long ago. But the last 6 months or so it's done great.

It's also far better than me (as someone who has done assembler since the Commodore 64) at using gdb to debug it, despite being effectively stuck using it in batch mode (which I didn't even knew existed). Watching it write elaborate scripts to dig into a code generation bug in my compiler is something.

I feel like the problem used to be that it'd struggle with the ambiguity of flow that is much more apparent in a high level language. But clearly that's not a problem any more.

Re: Frame – Linux X server in Assembly

#83

Post by vidarh »

kees99 wrote: post #30
adrian_b wrote: post #16

When first looking at the source code, I wondered why one would waste so much time to write 25k lines in raw assembly language, but then I saw that it was generated with Claude, for whom it does not matter much how expanded is the written text. 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 numb…

Claude has surprisingly good knowledge of X11 protocol. 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.

Yeah, I've had it work on an X11 server using a Ruby X11 protocol implementation instead of libX11, and it just rushed ahead and added support for a bunch of missing requests and responses. None of that is hard - it's all very well documented - but it's tedious.

My terminal emulator using the same binding also started out hand-written but Claude overhauled that too recently and it knows vtxx escape codes far better than me too.

Re: Frame – Linux X server in Assembly

#84

Post by bigyabai »

orphereus wrote: post #80
idiotsecant wrote: post #45

Earlier quoted context omitted.

There is evidence that LLMs are capable of making assembly that runs a great deal more efficiently than the compiler can manage on its own.

This has got to be the craziest AI-shill sentence I have heard in a long time. How can a generic LLM generate better assembly than a dedicated compiler, whose sole purpose is to generate assembly code. With people pedantically adding every optimization imaginable and unimaginable to produce the most efficient code possible. And you have the audacity to say LLMs, which write garbage non-trivial amount of time, are cap…

Agreed. "Evidence" in this case is a weasel word that could be anything. Misconfigured LLVM? Old/unsupported GCC target? Doesn't matter, look at the evidence of great success! This 10kb assembly loop has a 44,000% speedup versus compiling with automatic vectorization disabled!

LLMs generating "assembly that runs a great deal more efficiently" is a ludicrous claim that cannot be substantiated outside PEBCAK situations.

Re: Frame – Linux X server in Assembly

#86

Post by iberator »

adrian_b wrote: post #16

When first looking at the source code, I wondered why one would waste so much time to write 25k lines in raw assembly language, but then I saw that it was generated with Claude, for whom it does not matter much how expanded is the written text. 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 numb…

assembler is fun and kinda easy. easier than learning any JS framework in my opinion serious here.

Modern macro assemblera are fun

Re: Frame – Linux X server in Assembly

#87

Post by gspr »

vitally3643 wrote: post #68
ToyKeeper wrote: post #13

It's funny to see someone using a LLM as a compiler, making it convert higher-level operations into assembly, instead of just using a compiler.

Given how few programmers very seriously write lots of assembly, it's kind of astonishing how good LLMs are at working with assembly. They can compile and decompile all on their own with apparently very little effort. 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…

I've had the opposite experience. Inspired by a recent HN post where someone made the world's dumbest browser by having an LLM read HTML and draw the rendered page, I thought I'd do a fun art project and take it a notch dumber: have the LLM "be" the computer and execute code as a VM. I chose a simple instruction set that I thought would be very present in the training material (RV32IM), and defined a very simple machine model with flat memory and two trapped calls (to terminate and to request to print).

I couldn't once get any of the SoTA models from a month or two ago to correctly execute more than the first 5% of the instructions for a fizzbuzz (compiled from C with GCC). As I recall, one of the Qwens did the best and would only mess up "a little bit", but that's of course enough to derail everything (can someone remind me again why we think natural language is good for interacting with precise machines?). I didn't think it'd go very well, but failing at decoding something as well-documented as RISCV is not very impressive!

Most models would also start gaslighting me when I pointed out their mistakes. To their credit, they'd very often cheat by deducing that the code was for fizzbuzz, and try to fake the execution. Always badly though. (This despite explicit instructions to execute the code faithfully instruction by instruction and not be informed by their overview of the code).

I honestly don't understand how people can work like that. I had fun because the whole thing was a joke, an art project. Doing serious work in that way must be so ridiculous.

But then again, I don't use LLMs very much and might be holding them wrong.

Re: Frame – Linux X server in Assembly

#88

Post by fc417fc802 »

izacus wrote: post #79
fc417fc802 wrote: post #72

Earlier quoted context omitted.

It's also an 80% solution, the same thing so many rust "rewrites" are notorious for. Sure it finally mostly works at this point. Mostly. But it took a decade of kicking and screaming to get here and there are still edge cases that don't work, many clearly viewed as wontfix simply because there isn't enough popular support to force the hand of the purists. Hopefully llms make a community bootleg wayland protocol effor…

That's a bit dishonest since you're forgetting about all those features that now work, aren't you?

Not at all. "Sure it finally mostly works at this point. Mostly." I explicitly acknowledged that after 10+ years of needless drama something like 95% (handwave) of the extended feature list is working.

And so much of it really was needless drama. Go read through many of the wayland protocol extension issue tracker threads. The amount of intentional heel dragging, willful ignorance, and purity spiraling is off the charts (IMO obviously).

To be clear I like and use wayland in its current state. There are plenty of valid criticisms of X11. IMO a redo was not a bad idea per se and it eventually turned out well enough (provided your app doesn't depend on the 5% that suffers an arbitrary rejection).

Re: Frame – Linux X server in Assembly

#89

Post by vidarh »

Kelteseth wrote: post #18
yjftsjthsd-h wrote: post #8

I am loving the shift from 'X11 is too big and messy to ever reimplement' to 'there are multiple wildly different X servers being built from scratch'. 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 r…

> 'there are multiple wildly different X servers being built from scratch' by claude code. So this was only possible since no human had to bear looking at X original source code.

I think not looking at the original X source code is probably a good thing. The protocol is reasonably well specified, and you can further use the XML specification used for XCB. Most of the requests are pretty simple.

For some of the trickier ones it might be worth diving into an X11 implementation, but you can also defer most of the trickier ones other than getting the event handling right (most of the old school drawing API mostly matters if you want to run 30+ year old software that hasn't been updated much since; that said it might be nice to be able to run twm and xeyes - I have a whole separate file in my own X11 server for legacy stuff required to run twm and xeyes and similar ancient software, but not useful for anything else I actually care to run...)

Re: Frame – Linux X server in Assembly

#90

Post by im3w1l »

orphereus wrote: post #80
idiotsecant wrote: post #45

Earlier quoted context omitted.

There is evidence that LLMs are capable of making assembly that runs a great deal more efficiently than the compiler can manage on its own.

This has got to be the craziest AI-shill sentence I have heard in a long time. How can a generic LLM generate better assembly than a dedicated compiler, whose sole purpose is to generate assembly code. With people pedantically adding every optimization imaginable and unimaginable to produce the most efficient code possible. And you have the audacity to say LLMs, which write garbage non-trivial amount of time, are cap…

One simple thing that LLM's doesn't have to do is use a calling convention. Compilers need to use them, at least to some extent because it's not known at compile time who will link against this function in the future. Humans kinda need them because it's a lot of mental load when everything is custom. But for a sufficiently smart llm, noticing a register doesn't need to be preserved because there is only two callers and neither of them care about it might be doable.
Post reply on HN