Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My application programmer instincts failed when debugging assembler

landedstar.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: My application programmer instincts failed when debugging assembler

#21

Post by throwaway94275 »

jagged-chisel wrote: post #12

I think lots of commenters are being unintentionally pedantic. It’s clear that there are different types of abstractions one is concerned with when programming at the application level. Yes, it’s all abstractions on top of subatomic probability fields, but no one is thinking at even the atomic level when they step through the machine code execution with a debugger.

The one abstraction you would have to keep in mind with assembler (writing more than reading tho) is the cache hierarchy. The days of equal cost to read/write any memory location are ancient. Even in the old 8 bit days some memory was faster to access than others (e.g. 6502 zero page).

The flags are another abstraction that might not mean what it says. The 6502 N flag and BPL/BMI instructions really just test bit 7 and aren't concerned with whether the value is really negative/positive.

Re: My application programmer instincts failed when debugging assembler

#22

Post by TacticalCoder »

xg15 wrote: post #11

> Abstractions. They don’t exist in assembler. Memory is read from registers and the stack and written to registers and the stack. [...] But my application-coded debugging brain kept looking at abstractions like they would provide all the answers. I rationally knew that the abstractions wouldn’t help, but my instincts hadn’t gotten the message. That feels like the wrong takeaway for me. Assembly still runs on abstrac…

> Assembly still runs on abstractions: You're ignoring the CPU microcode ...

Yes and no. There's no way to "get" to these. Arguably assembly is an abstraction on top of codes (hexcodes or binary if you want to see it that way), but the assembly instructions are the lowest level we get to access. For as a programmer you don't get to access the microcodes emulating an amd64 architecture and you cannot decide to use these microcodes directly.

Otherwise it's just electricity. Then it's just electrons.

So it's not false that it's all abstractions but it doesn't help much to view it that way.

Re: My application programmer instincts failed when debugging assembler

#23

Post by zahlman »

userbinator wrote: post #4

Asm is simple enough that "mental execution" is far easier, if more tedious, than in HLLs, especially those with lots of hidden side-effects. The concept of a function doesn't really exist (and this is even more true when working with RISCs that don't have implicit stack management instructions), and although there are instructions that make it more convenient to do HLL-style call and return, it's just as easy to wri…

> Asm is simple enough

The general conceptual model of "asm" is simple.

Some instruction sets and architectures are hideous, though.

> merely being a human compiler is not particularly enlightening nor useful.

I don't think I can agree with that. At least it teaches you what the compiler is doing. And abiding by conventions (HLL-esque control flow, but also things like "put the return value in r0" and "put constant pools after the function") can definitely make it easier to make sense of the code. (Although you might share a constant pool across a module or something, if the instructions reach far enough.)

Not to say that you can't do interesting things, and can't ever beat the compiler. One of the things I most enjoyed discovering, in mid-00s era THUMB (i.e. 16-bit ARM) code, is that the compiler was implementing switch statements with tables of 32-bit constants that it would load into an indirect jump. I didn't get around to it, but I figured I could mechanically replace these with a computed jump into a "table" of 16-bit unconditional branches (except for very long functions, but this helped bring the branch distances under thresholds).

Re: My application programmer instincts failed when debugging assembler

#24

Post by zahlman »

nurettin wrote: post #19

Coming from pascal to C as a highschooler, my biggest wtf moment happened when I forgot a ; after a struct in a header. The compiler kept complaining about the code below the include and for the life of me I couldn't figure it out. Took me another hour to reason that the includes must be concatenating invalid code.

Ah, that's nostalgic.

I haven't done serious work in C in quite some time. I wonder if modern compilers are better at reporting that sort of thing.

Re: My application programmer instincts failed when debugging assembler

#25

Post by userbinator »

mathisfun123 wrote: post #20
RobotToaster wrote: post #9

Earlier quoted context omitted.

there's an interesting new API skill for the human cortex v1.0, that allows for a much larger context window, it's called pen and paper.

What do the words "mental execution" mean?

Using your brain and not the machine.

Re: My application programmer instincts failed when debugging assembler

#26

Post by leptons »

xg15 wrote: post #11

> Abstractions. They don’t exist in assembler. Memory is read from registers and the stack and written to registers and the stack. [...] But my application-coded debugging brain kept looking at abstractions like they would provide all the answers. I rationally knew that the abstractions wouldn’t help, but my instincts hadn’t gotten the message. That feels like the wrong takeaway for me. Assembly still runs on abstrac…

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 electrons.

Embedded CPU assembly is what I do most often, for the last 40 years, and there aren't really any abstractions at all - not even microcode. You have a few KB or ROM and maybe a few KB of RAM, ALU, registers, peripherals, and that's it - no APIs, no kernel, no system calls, no stdlib. Just the instructions you burn into the ROM.

Re: My application programmer instincts failed when debugging assembler

#27

Post by leptons »

throwaway94275 wrote: post #21
jagged-chisel wrote: post #12

I think lots of commenters are being unintentionally pedantic. It’s clear that there are different types of abstractions one is concerned with when programming at the application level. Yes, it’s all abstractions on top of subatomic probability fields, but no one is thinking at even the atomic level when they step through the machine code execution with a debugger.

The one abstraction you would have to keep in mind with assembler (writing more than reading tho) is the cache hierarchy. The days of equal cost to read/write any memory location are ancient. Even in the old 8 bit days some memory was faster to access than others (e.g. 6502 zero page). The flags are another abstraction that might not mean what it says. The 6502 N flag and BPL/BMI instructions really just test bit 7 a…

Ooof I remember the bank switching on PIC microcontrollers was particularly awful. I still got it to work, but it wasn't very fun.

Re: My application programmer instincts failed when debugging assembler

#28

Post by david-gpu »

leptons wrote: post #26
xg15 wrote: post #11

> Abstractions. They don’t exist in assembler. Memory is read from registers and the stack and written to registers and the stack. [...] But my application-coded debugging brain kept looking at abstractions like they would provide all the answers. I rationally knew that the abstractions wouldn’t help, but my instincts hadn’t gotten the message. That feels like the wrong takeaway for me. Assembly still runs on abstrac…

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.

Re: My application programmer instincts failed when debugging assembler

#29

Post by david-gpu »

TacticalCoder wrote: post #22
xg15 wrote: post #11

> Abstractions. They don’t exist in assembler. Memory is read from registers and the stack and written to registers and the stack. [...] But my application-coded debugging brain kept looking at abstractions like they would provide all the answers. I rationally knew that the abstractions wouldn’t help, but my instincts hadn’t gotten the message. That feels like the wrong takeaway for me. Assembly still runs on abstrac…

> Assembly still runs on abstractions: You're ignoring the CPU microcode ... Yes and no. There's no way to "get" to these. Arguably assembly is an abstraction on top of codes (hexcodes or binary if you want to see it that way), but the assembly instructions are the lowest level we get to access. For as a programmer you don't get to access the microcodes emulating an amd64 architecture and you cannot decide to use the…

> Otherwise it's just electricity

There is a lot going on at the hardware level that is going on and hidden from the view of assembly. Hardware is not magic, there are a ton of design decisions that go into every architecture, most of which isn't immediately obvious by looking at the ISA.

Re: My application programmer instincts failed when debugging assembler

#30

Post by iberator »

xg15 wrote: post #11

> Abstractions. They don’t exist in assembler. Memory is read from registers and the stack and written to registers and the stack. [...] But my application-coded debugging brain kept looking at abstractions like they would provide all the answers. I rationally knew that the abstractions wouldn’t help, but my instincts hadn’t gotten the message. That feels like the wrong takeaway for me. Assembly still runs on abstrac…

Thats BS.

You can totally convert your assembly into machine code by hand. There is no lower level. Not all cpus have microcode.

Post reply on HN