HN Reader

This is more like "by communicating with the X server", which is not exactly the level of "from scratch" I was expecting, but then again, it's more involved than the equivalent in Win32 that's not much more than filling in some structures and invoking a few functions.

I learned X86 ASM by sinking my teeth into the Intel 8085 manual, then lighting up LEDs on a hardware emulator and later on a 8085 simulator that me and my brother built.

What certainly helped was that I had did some digital design and instruction set architecture, etc.

Later on, I did some real-world assembly programming for the PIC microcontrollers and some inlined assembly in C, which I did not find daunting at all because of my previous experience.

I guess the best prerequisite for this material is having done some low-level C, the kind where you know about text/data sections and being comfortable with calling conventions, the run time and the linking process.

This reminds me of the time I was a young, naïve idiot, and decided I would learn GTK by writing some basic app in GTK. In x86 (not x86-64) assembly. Like all of my other project ideas from that era, never went anywhere, and I horribly underappreciated just how complicated things were.

Kudos for actually getting somewhere in their attempt to do this, a further state than I ever managed.

Corresponding Windows article: https://bitcodersblog.wordpress.com/2017/05/10/win32-in-nasm...

(but yes, I also would have expected a bit more "from scratch". Is there an annotated disassembly of, say, AmigaOS around?)

Previously:

Learn x86-64 assembly by writing a GUI from scratch - https://news.ycombinator.com/item?id=36153237 - June 2023 (146 comments)

Using X11 isn't exactly from scratch.

I was curious about the rep movsb, so I tried to compare this with how a compiler would copy a known small size chunk of memory. It seems pretty complicated. I didn't manage to make a compiler generate the `rep movsb` idiom but I managed to find out some interesting stuff:

- small, known size moves are stitched from a fixed number of mov instructions, sometimes overlapped. For example 21 bytes is qword (8 bytes) + xmmword (16 bytes), overlapped.

- char-copying loops like "a++ = b++ c times" with c not known at compile time are either realized as simple increase, compare, conditional jump, or, at higher optimization, a monster that has like 10 branches to use anything from xmmword to byte depending on the amount of data

- big, known size moves (> 256 bytes) just generate a call to memcpy

I have to say, writing a GUI is one of the last places I’d ever find it appropriate to use assembly language. Man, those click handlers are going to be fast.

Does anyone know of a C version of this, communicating with the X server without libraries?

(on Linux/X11, which should have been mentioned in the title)

XQuartz does not support high resolution displays, that is not what macOS users looking for.