My application programmer instincts failed when debugging assembler • Hacker News Board

Re: My application programmer instincts failed when debugging assembler

#31

Post by leptons » Sun, Mar 08, 2026, 1:20 AM UTC

david-gpu wrote: post #28

leptons wrote: post #26

Earlier quoted context omitted.

No, assembly doesn't always inherently deal with abstractions. It depends on the system involved. I don't really count "microcode" as an abstraction, it's essentially part of the hardware and doesn't even exist on many embedded CPUs. The assembly instructions for all intents and purposes operate directly on the hardware. If you wanted to get really absurd with it, you could say that all of it is an abstraction of ele…

Depending on the ISA, assembly is quite abstracted away from the actual underlying hardware, at least from the viewpoint of a computer architect. It depends on the ISA, of course. Many common hardware features like out of order instruction issuing, register renaming, and even largely caching and segmentation, are largely or entirely hidden at the assembly level.

Maybe you missed the part where I described that not all CPUs work the same, not all have out of order instruction issuing, register renaming, or even any cache at all. OP was blanket talking about assembly, without realizing the many different kinds of CPUs out there, and apparently you're here cherry-picking too.

I have no interest in continuing this pointless internet interaction.

Re: My application programmer instincts failed when debugging assembler

#32

Post by david-gpu » Sun, Mar 08, 2026, 12:43 PM UTC

leptons wrote: post #31

david-gpu wrote: post #28

Earlier quoted context omitted.

Depending on the ISA, assembly is quite abstracted away from the actual underlying hardware, at least from the viewpoint of a computer architect. It depends on the ISA, of course. Many common hardware features like out of order instruction issuing, register renaming, and even largely caching and segmentation, are largely or entirely hidden at the assembly level.

Maybe you missed the part where I described that not all CPUs work the same, not all have out of order instruction issuing, register renaming, or even any cache at all. OP was blanket talking about assembly, without realizing the many different kinds of CPUs out there, and apparently you're here cherry-picking too. I have no interest in continuing this pointless internet interaction.

Ok.

Re: My application programmer instincts failed when debugging assembler

#33

Post by wiz21c » Sun, Mar 08, 2026, 4:49 PM UTC

Kiboneu wrote: post #14

wiz21c wrote: post #8

Earlier quoted context omitted.

Abstractions pretty much exist and in assembler they matter even more because the code is so terse. Now, there are abstractions (which exist in your brain, whatever the language) and tools to represent abstractions (in ASM you've got macros and JSR/RET; both pretty leaky).

That wasn’t my point. You almost got there when you wrote “there are abstractions (which exist in you brain, whatever the language)”. And your point on leaky abstractions is exactly the indication that they exist in your mind, not out there. My point is that we settle with what we see for convenience/utility and base our models on that. We build real things on top of these models. Then the result meets reality. If on…

> My point is that we settle with what we see for convenience/utility and base our models on that.

I disagree with that. My abstractions are pure in my mind (well, I hope even if it sounds a bit pretentious). I try to get the best out of the tools I have at hand to represent them. I'm perfectly fine with leaky abstractions, mismatches, inconvenent languages, etc. I live with that. But I certainly don't actively seek these leaks. Quite the opposite :-) (well instead I'm pursuing another goal like performance, in which case, I blow abstractions away). Oh, and in case you wonder, I did write tons of assembly on 8086/80386 and 6502 and now I'm full on on rust, julia and python. I know what an abstraction is :-)

But I thnk we globally agree nonetheless

Re: My application programmer instincts failed when debugging assembler

#34

Post by BXLE_1-1-BitIs1 » Sun, Mar 08, 2026, 9:23 PM UTC

As an ancient mainframe Assembler programmer, I first learned Assembler from studying the code generated by the compiler. There are traps in compiler languages calling user written Assembler routines. The first one I encountered was a routine that could return to different addresses in the calling program. That worked as long as the address was in the same routine, but if the return address was farther up the calling chain (eg. A > B > C The application programmers ended up with a dump and had no idea on how to diagnose the problem. I once walked up to a programmer puzzled by a dump and solved it in about three minutes (practice helps) putting out of joint the nose of the senior programmer who was being consulted.

The compiler library handled this situation just fine, but the guru who wrote the Assembler program insisted that programmers had to be more careful.

I wrote another routine to intercept the calls and use the subroutine library when needed.

Re: My application programmer instincts failed when debugging assembler

#35

Post by BXLE_1-1-BitIs1 » Sun, Mar 08, 2026, 9:32 PM UTC

Assembler programs are written for different environments: Ordinary applications, Accessing OS facilities the compiler language can't access, extending the OS, Device control, enhancing boot process...