Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Haha, it's almost like some detective short story.

Surprisingly it wasn't as hard to follow as I thought. Maybe I'm starting to get good at this Computer Science thing.



Must be my fantastic writing.

Seriously though, assembly isn't all that hard, mentally. It's difficult in the same way that unloading a truck full of sand with your bare hands is difficult. Which is to say, it takes a long time, but all it really needs is time, not deep thought.

People get scared away from it because they don't know where to start with it, or because it looks really hard, or because it just takes too much time to understand what's going on, but it can be really rewarding.


I think the hard part mentally (that your incredibly great explanation completely alleviated) is trying to guess at the meaning of the interplay of all the instructions, addressing modes, register overlaps, and calling conventions. It seems like the only way to turn that from difficult (impossible) guess-work to mere sand-unloading drudgery is to either have a lot of it memorized already, or to have a very strong command over the various documentation resources.


Being old enough have coded full applications in plain Assembly, I think it is a lost that not many developers know Assembly nowadays.

At least to be able to grasp what a piece of code might do, not necessarily to write code.


Or because they don't see immediate value in it, as typical programming isn't done in ASM nowadays. I think it's worthwhile just to "demystify" computers, but since embedded programming, demos and retro gaming are part of my interests, I get practical benefits out of it as well.


True, but when it comes in handy it can be immensely so. I was looking at a customer crash dump at work the other day and the callstack shown by two different debuggers didn't make any sense, it was showing calls sequences the code clearly didn't make. Looking at the raw stack in memory and using the disassembly to help see the layout of the frames made it (relatively) easy to see there were a couple of calls in the sequence that both debuggers simply weren't showing. Once I had the real sequence and the dissassembly to see how the frames evolved and recompute call targets for earlier in the frames life it became a lot easier to see what was going wrong. If I hadn't been able to do that (and my ASM skills are definitely not strong) this would have been a No Repro (and hence no fix) bug for sure.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: