Hacker RealtimeBuilt with Neon Realtime
connecting… · checking source…

Comment on Hacker News

  1. > I’ve developed an unusual little nighttime routine: after reading bedtime stories to the kids, I hop into bed and instead of reaching for a fiction book, I’m turning on my 14-year old Asus eeePC 701 (wikipedia.org) miniature laptop and writing x86 assembly language

    I don’t understand how people do this without wrecking their sleep. I’m studying to be a CPA and that little One More Thing just before bed time totally wrecks my sleep. Studying (even something as boring as tax laws) gets my mind excited and I’ll be up till 6am no matter how physically/mentally tired I am.

    reply
  2. Here’s an archive.org mirror of the broken “Why no one should use the AT&T syntax ever, for any reason, under any circumstances” link: https://web.archive.org/web/20251128060318/https://outerprod...
    reply
  3. Anyone noticing some pretty heavy skill atrophy from all the Claude/Codex use in the last few months?

    I feel like this is a great way to get back to basics and keep the eng skills sharp. Maybe I should try something similar...

    reply
  4. I wouldn't call it "atrophy" unless you were already reading and writing Asm regularly.
    reply
  5. Why would one choose NASM over FASM? The makers of KolibriOS (an OS written entirely in assembler) chose FASM but the reason eludes me.

    To me all assemblers look alike and it would even be feasible to write one's own just for the heck of it.

    reply
  6. I have not used FASM so I can't comment on it, but there are quite large differences between assemblers in general. Each is essentially a (non-optimizing) compiler for a different extension language. Writing your own assembler that literally just assembles is trivial, but writing raw assembly instruction by instruction is tedious and not especially practical. If you're serious about writing it, you'll want macros and other forms of metaprogramming; as a programmer, the entire point of your existence is to automate tedious, repetitive tasks, and better assemblers help with that. Programming your own assembler is a natural progression of metaprogramming if you stick with assembly long enough, but first you should learn with using an existing one so you can begin to understand your own workflow well enough to know what tools you want for reducing repetition and where the existing one falls short.
    reply
  7. And why not? You can just use CALL and make subroutines for repetitive tasks. Why would one need macro functionality which is basically inlining code like in C/C++. Inlining also makes the executable needlessly large. It may have its uses but I suspect most of the time just calling a function or subroutine is more desirable.
    reply
  8. Calls have overhead, so they shouldn't be used for everything, especially in hot paths. The entire point of writing assembly is to optimize performance. Even on very limited systems, or rather especially on limited systems, you'd usually much rather trade code size for performance.
    reply
  9. Using GDB to debug Asm is... certainly a choice.
    reply
  10. Why? Back in the day, after the pain of debugging on Timex, and MS-DOS debug, the confort of Turbo Assembler debugger felt really nice.
    reply
  11. Gdb is an excellent debugger for assembly, even when the original code was written in C

    I would automatically type

    (gdb) x/4i $pc

    when opening a coredump out of habit.

    But using nasm, then looking as gas style assembly in the debugger might be a bit more jarring.

    reply
  12. We had better tools 30 years ago when pure assembly work was more common. You'd often run in the debugger by default.

    Yet GDB lives on

    reply
  13. What's the better choice?
    reply
  14. Setting a breakpoint in the debug registers DB0 through DB7 and dumping registers and memory in your own debug exception handler.
    reply
  15. 1 day ago
    [deleted]
  16. [dead]