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

61–70 of 115 posts

Re: Frame – Linux X server in Assembly

#61

Post by amszmidt »

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.

Only because the X Window System is very heavily documented, e.g., in the excellent "The Definitive Guides to the X Window System Series".

Re: Frame – Linux X server in Assembly

#63

Post by asveikau »

I can have a machine generated X server in assembly too. It's called cc -s.

Or:

   $ objdump --disassemble /usr/lib/xorg/Xorg
Maybe I'm getting too old for this, but I really don't see the point in having AI generate assembly code for this.

Re: Frame – Linux X server in Assembly

#64

Post by duskwuff »

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.

"Congratulations! You've reinvented compilers, except slower, unpredictable, hopelessly proprietary, and you have to pay to use it."

(Oh, and the "compiler" will also refuse to generate certain types of programs.)

Re: Frame – Linux X server in Assembly

#67

Post by asveikau »

kees99 wrote: post #40
glitchc wrote: post #35

Earlier quoted context omitted.

No libc? It used inline assembly routines?

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.

Re: Frame – Linux X server in Assembly

#68

Post by vitally3643 »

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 of C. And we all know how much C code exists online.

Re: Frame – Linux X server in Assembly

#69

Post by cogman10 »

Aurornis wrote: post #48
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…

It’s an interesting strategy, but I question how much it pays off, if at all. Very few parts of a program benefit from manually tuned assembly compared to the naive C implementation. Writing everything in assembly adds an extra layer of thought, which even for an LLM is additional effort that could have been used for targeted optimizations instead. It makes it harder to notice patterns that have been trained into the…

It will make the code slower.

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.

Re: Frame – Linux X server in Assembly

#70

Post by vitally3643 »

kibwen wrote: post #54
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.

The purpose of an optimizing compiler is not merely to produce efficient assembly. The goal of an optimizing compiler is to produce efficient assembly while confidently preserving a program's observable logical semantics. Asking an LLM to spit out raw unstructured assembly based on inferred context from a specification given in English is a contender for one of the worst ideas I have ever heard; I award you no points…

Code is code my dude. If an LLM can turn English into Python, there's really no reason it can't do assembly. Assembly is not magic, it's just code that humans find difficult to grok. LLMs, it would seem, don't have the same kind of trouble understanding assembly that humans do.

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.

Post reply on HN