FRESH

Hacker News

My application programmer instincts failed when debugging assembler

45 points by lifefeed

by xg15

3 subcomments

> 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 abstractions: You're ignoring the CPU microcode, the physical interaction with memory modules, etc. If the CPU communicates with other devices, this has more similarities with network calls and calling the "high level APIs" of those devices. For user space assembly, the entire kernel is abstracted away and system calls are essentially "stdlib functions".
So I think it has a different execution model, something like "everything is addressable byte strings and operates on addressable byte strings". But you can get that execution model occasionally in high-level languages as well, e.g. in file handling or networking code. (Or in entire languages built around it like brainfuck)
So I think assembly is just located a few levels lower in the abstraction pile, but it's still abstractions all the way down...

by userbinator

4 subcomments

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 write a "function" that returns to its caller's caller (or further), switches to a different task or thread, etc. If you're going to learn Asm, then IMHO you should try to exploit this freedom in control flow and leverage the rest of the machine's ability, since merely being a human compiler is not particularly enlightening nor useful.

by Surac

0 subcomment

I was luck to learn asm on a very simple 8 bit CPU (6502). It had a very limited register set (3) and instruction count. I think if you realy like to dive into the ASM topic try to find a small easy CPU model and use a emulator to run your code

by BXLE_1-1-BitIs1

0 subcomment

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 < A). A would crash running B's registers.
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.

by Chaosvex

1 subcomments

Not sure what to take away from this. __abstract works because GCC allows it as an alias to __abstract__, not because parsing the syntax is forgiving.
Abstractions do exist (disagreeing with the single other post in here) and they also exist in most flavours of assembly, because assembly itself is still an abstraction for machine code. A very thin one, sure, but assemblers will generally provide a fair amount of syntactic sugar on top, if you want to make use of it.
Protip: your functions should be padded with instructions that'll trap if you miss a return.

by jagged-chisel

1 subcomments

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.

by nurettin

1 subcomments

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.

by BXLE_1-1-BitIs1

0 subcomment

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

by david-gpu

1 subcomments

My unsolicited friendly advice to software folks who are curious about assembly languages is: ask yourself what is it that you expect to get out of it.
If you want a better understanding of the architecture, reading the documentation from the hardware vendor will serve you better.
If you want your code to be faster, almost certainly there will be better ways to go about it. C++ is plenty fast in 99% of the situations. So much so that it is what hardware vendors use to write the vast majority of their high-performance libraries.
If you are just curious and are doing it for fun, sure, go ahead and gnaw your way in. Before you do so, why not have a look at how hand-written assembly is used in the rare niches where it can still be found? Chances are that you will find C/C++ with a few assembly intrinsics thrown in more often than long whole chunks of code in plain assembly. Contain that assembly into little functions that you can call from your main code.
For bonus brownie points, here is a piece of trivia: the language is called assembly and the tool that translates it into executable machine code is called the assembler.

by Kiboneu

1 subcomments