Hacker News Reader

Comment by hirvi74 | Hacker News Reader

I have no idea what the parent meant by, "My guess is that your ASM is inflected by structured programming everywhere."

(I am the GP)

Your response was far better than mine. If those instructions were executed more than a couple of times and the constraints/assertions were identical, I'd absolutely throw them in a function. I'll handle what I need to before/after the function.

I would never branch to some coincidental label. That is why I love ASM so much. If you are sloppy or lazy, you will most likely be punished severely for those choices.

(Tangential, but when I first learned ASM in college, I felt like I learned more in that one semester than all the sum of all classes in my entire degree.)

View on HN

By "inflected by..." I'm suggesting that Structured Programming has altered how you write assembler even though of course assembler doesn't inherently provide that structure.

When you need to do X here and there, you write code to X and then you call it where it was useful - you don't have code in one function just jump to a label in a completely different function because, in this era where structured programming is taken for granted - that seems crazy. And it is, but only the same way that chattel slavery seems crazy today, in the Antebellum South it was just usual and likewise in 1950s computer software just jumping into unrelated code was normal.

One of the principles of structured programming is that you organize your code into functions, and that they have single points of entry, and single points of exit. We still have a lot of multiple points of exit in functions these days, but the reasons for them usually fall into either those of clarity (less nesting/branching) or performance by skipping unnecessary work, and the consequences of them are less dire in modern high level languages because such languages have GC (no fear of skipping a memory cleanup step) and features like try..finally to ensure code closing file handlers or logging or whatever is executed at the end. But we have largely eliminated multiple points of entry from most code. The main remnant I can think of is in the form of coroutines, though they are structured and limited enough (like modern gotos) and have well defined lifecycles that it's more forgivable.

Reply on news.ycombinator.com