> There weren't really any new concepts to grasp, it was just extremely fiddly
> The need to keep things simple tempered any urge I might've had to generalise prematurely with needless abstraction
Probably the defining characteristics of assembly. Not only does it not provide abstractions, it doesn't provide any metaprogramming tools (other than simple text macros) to help you build any either.
For a long time I've had in my ideas folder the phrase "typesafe macro assembler?" The idea would be to build the language people sometimes think C is but isn't: it would provide some sort of record type (struct), register allocation, checking to see if you've assigned one thing to a storage location of a different type, and little else. Possibly a means to define a calling convention for caller-saved vs callee-saved registers; possibly some basic structured programming block tools to de-sphagetti your code. Crucially, it would emit exactly the operations you specify (including weirder mnemonic instructions and highly platform specific ones) in the order you specify them.
I did roughly the same thing many moons ago as the final "exam" for my undergraduate embedded systems course. We made Space Invaders, though :^) https://github.com/tuckerpo/MicroSpaceInvaders
We targetted a real SoC, though, so a lot of my implementation can be thought of as a "board support package" or HAL, twiddling LEDs, taking in input, TTY in/out, i2c, timers, IRQ/FIQ handlers, etc...
Assembly programming in general is more or less just getting a feel for any given ISA's most important instructions, mnemonics ordering and data/code separation. The rest is a walk in the park if you're comfortable with boring old procedural programming.
Thanks for sharing your experience learning assembly. I'm curious about the resources you used in your learning journey. Could you share some of the books name, tutorials, or other materials you found particularly helpful?
Sadly it doesn't work on my system: the display is drawn at the start (sometimes partially), and then only ever updates when switching between virtual consoles.
Tried adding O_SYNC to the open flags for the framebuffer, and it didn't help. It's writing to the device 60 times per second, just won't show for some reason.
Interesting, I’ve only tried it on two machines - my (fairly old) laptop with integrated graphics and my desktop with an RTX4060. I’ve also tried it on the desktop on Windows in a Linux VM running Ubuntu 24.04. It runs way smoother on the laptop.
Thanks for trying it :)
BTW, is there a problem with the JavaScript on my website?
In case you're still reading this, I tried a more mature program using the framebuffer (fbi image viewer), and it had exactly the same problem! I now suspect it has something to do with the Intel graphics driver (i915), either a bug or more likely some undocumented interaction with the console.
It's really too bad how the Linux kernel provides these APIs, but barely any documentation, and the only way you're supposed to interact with them is through some specially "blessed" abstraction layer running in userspace (X11/Wayland/SDL, pulseaudio, etc.) which inevitably demands linking in C libraries.
Now I've at least got it working on an old laptop with 1366x768 resolution :)
Well, not immediately. At first there was an entirely different problem: everything on the screen was garbled!
However it was easy to figure out why and fix it: depending on the hardware and resolution, lines in the framebuffer can have extra padding beyond what's needed for the visible pixels. That information is available in another info structure:
; Get size of line in framebuffer
mov eax, 16 ; sys_ioctl
mov edi, [drw_fbfd]
mov esi, 0x4602 ; FBIOGET_FSCREENINFO
mov rdx, rsp
syscall
mov eax, [rsp+0x30] ; bytes per line
shr eax, 2 ; convert to pixels
mov [drw_fb_pitch], eax
There are only a few places in draw.asm that then need to be changed to multiply by this new variable instead of drw_fb_w.
> There weren't really any new concepts to grasp, it was just extremely fiddly
> The need to keep things simple tempered any urge I might've had to generalise prematurely with needless abstraction
Probably the defining characteristics of assembly. Not only does it not provide abstractions, it doesn't provide any metaprogramming tools (other than simple text macros) to help you build any either.
For a long time I've had in my ideas folder the phrase "typesafe macro assembler?" The idea would be to build the language people sometimes think C is but isn't: it would provide some sort of record type (struct), register allocation, checking to see if you've assigned one thing to a storage location of a different type, and little else. Possibly a means to define a calling convention for caller-saved vs callee-saved registers; possibly some basic structured programming block tools to de-sphagetti your code. Crucially, it would emit exactly the operations you specify (including weirder mnemonic instructions and highly platform specific ones) in the order you specify them.
This actually has already been done in OS research.
https://en.m.wikipedia.org/wiki/Verve_(operating_system)
https://en.m.wikipedia.org/wiki/Typed_assembly_language
Which eventually grew to stuff like this,
https://github.com/project-everest/vale
I did roughly the same thing many moons ago as the final "exam" for my undergraduate embedded systems course. We made Space Invaders, though :^) https://github.com/tuckerpo/MicroSpaceInvaders
We targetted a real SoC, though, so a lot of my implementation can be thought of as a "board support package" or HAL, twiddling LEDs, taking in input, TTY in/out, i2c, timers, IRQ/FIQ handlers, etc...
Assembly programming in general is more or less just getting a feel for any given ISA's most important instructions, mnemonics ordering and data/code separation. The rest is a walk in the park if you're comfortable with boring old procedural programming.
Finally, someone who uses a sane build system! :D
Thanks for sharing your experience learning assembly. I'm curious about the resources you used in your learning journey. Could you share some of the books name, tutorials, or other materials you found particularly helpful?
non-JS URL: https://content.deadbeef.io/pages/a_cpp_developer_learns_ass...
Sadly it doesn't work on my system: the display is drawn at the start (sometimes partially), and then only ever updates when switching between virtual consoles.
Tried adding O_SYNC to the open flags for the framebuffer, and it didn't help. It's writing to the device 60 times per second, just won't show for some reason.
Interesting, I’ve only tried it on two machines - my (fairly old) laptop with integrated graphics and my desktop with an RTX4060. I’ve also tried it on the desktop on Windows in a Linux VM running Ubuntu 24.04. It runs way smoother on the laptop.
Thanks for trying it :)
BTW, is there a problem with the JavaScript on my website?
In case you're still reading this, I tried a more mature program using the framebuffer (fbi image viewer), and it had exactly the same problem! I now suspect it has something to do with the Intel graphics driver (i915), either a bug or more likely some undocumented interaction with the console.
It's really too bad how the Linux kernel provides these APIs, but barely any documentation, and the only way you're supposed to interact with them is through some specially "blessed" abstraction layer running in userspace (X11/Wayland/SDL, pulseaudio, etc.) which inevitably demands linking in C libraries.
Now I've at least got it working on an old laptop with 1366x768 resolution :)
Well, not immediately. At first there was an entirely different problem: everything on the screen was garbled!
However it was easy to figure out why and fix it: depending on the hardware and resolution, lines in the framebuffer can have extra padding beyond what's needed for the visible pixels. That information is available in another info structure:
There are only a few places in draw.asm that then need to be changed to multiply by this new variable instead of drw_fb_w.I might try it out on other machines or without running X at the same time. Maybe some conflict with the framebuffer console + X?
>BTW, is there a problem with the JavaScript on my website?
I just block all JavaScript by default, and strongly believe that websites should remain usable that way.
https://archive.is/d5tUv