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.
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.
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.
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.
14 comments
[ 2.8 ms ] story [ 38.2 ms ] threadKudos for actually getting somewhere in their attempt to do this, a further state than I ever managed.
In my youth, kids learned assembly to crack games.
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.
Learn x86-64 assembly by writing a GUI from scratch - https://news.ycombinator.com/item?id=36153237 - June 2023 (146 comments)
(but yes, I also would have expected a bit more "from scratch". Is there an annotated disassembly of, say, AmigaOS around?)
- 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