I mean, it's WSJ. 'Closing the book' is a common idiom in the accounting/business world with specific connotation around ending a project/line of business.
I think this is the biggest problem with learning x86 assembly (or ARM or anything else) on modern systems (or more specifically modern operating systems).
It’s sometimes difficult to think about the assembly code in situ when you start to think about the operating system doing a ton of context switching and paging etc. in the background, which can distract your thought process from what’s right in front of you (as well as the operating system’s software interrupts / system calls on top of the basic ISA, which is another abstraction!)
Older systems had the currently running program as the entire context of the system at that point in time - in a similar way to embedded programming, which is imho a much easier realm to learn assembly in once you’ve got a bit of basic electronics under your belt!
The whole point of how interrupt handling works is that it returns back to the same state of the program already in progress when finished. The abstraction is such that the interrupted program doesn't need to care.
Even in those "old" systems of single address spaces and no protection, you're constantly getting timer interrupts, interrupts for I/O, etc., which your application might not have installed its own handler for.
I agree - my main point is that an OS is ‘just a program’ as well
I suspect we’re both making a similar point in a roundabout way - the operating system is both another layer of abstraction on top of the Instruction Set, while also making the programming process for that chipset somewhat easier (providing software interrupts etc. at the expense of bare metal understanding).
My argument is loosely that modern (x64) assembly is not so much targeting hardware as it is programming into a software abstraction (the operating system).
The code above I believe is the point to jump to when the register has been assigned some value for x. Think along the same lines as a function call once the pre-amble is out of the way (or a ‘goto’ by someone who knows when to use it!)
I’d like to add to this comment to say that the author has a fantastic assembly course available on udemy - very thorough and practical (teaching the basics in a win32 environment)
Yes, I made the videos a few years ago. This video series is mostly for beginners as it goes pretty slowly.
The exercises are open source and can be found here:
https://github.com/xorpd/asm_prog_ex
I think that more experienced developers can take the instruction set and bash through the exercises.
I think it’s created by the man himself - having been through it it’s a very thorough coverage of the basic instruction set without delving too much into the windows specifics (it uses FASM syntax from what I recall)
>> if your code needs a comment to be understood, it would be better to rewrite it so it's easier to understand.
I both agree and disagree with this... C is a small language, and it shouldn't take a huge amount of time to parse the source code to find out what's going on if variables / function names are self-documenting etc.
However, if you're dealing with a large code base and trying to track down where a variable is declared (and subsequently defined) for the purposes of maintenance or updating legacy code, comments hinting the what the structure underneath that label represents are incredibly useful (and more importantly, time and energy saving)
I've been burned by bad comments enough times that I implicitly don't trust them. I wish this weren't the case but I think it's just human psychology. I'd rather unravel a mystery myself than deal with an unreliable narrator.
IDK, if you have self-documenting names, that sort of implies that they're close to unique/disambiguated. Which means that grep does a great job tracking down use (and declaration). And grep doesn't lie like out of date comments will.
I generally comment when I'm doing something really goofy because the 'obvious' method has some subtle flaw. A documentation for the next guy (who has a chance of being me, having forgotten some of the context six months form now) as a "I know you want to refactor this, but it's more complex than you think" warning.
This goes to "comments shouldn't describe the code, they should describe the reasoning". Especially if there are external reasons why the code is structured that way. On straightforward programs you should need hardly any comments at all.
It's a real shame that the last line of System V Unixes/ Unices / Unii is starting to die off. Market share aside, it's sad that the history of UNIX(r) appears to be coming to a close...
A very undignified end to a wonderful OS (BSDs aside!)
To clarify - I agree the BSDs are keeping Unix alive, however separating BSD from those Unixes with System V roots which are starting to wither and die is the point I was making - hence the (BSDs aside) addendum.
God I hope so. The last time I touched HP/UX was 2001. I still have nightmares. It's a wretched UNIX. It was running veritas, another wonderful pos software.
Oracle is killing Solaris. At least HP has a recent precedent with licensing the rights to another OS (VMS) to a separate company to let its life continue.
My concern would be that as they look to carve off the less profitable areas of their enterprise divisions, that the HP/UX team (as a smaller subset of the overall quoted number of 5000) and in turn the HP/UX product as it stands at the moment, could potentially be marked to suffer the same projected fate as Solaris.
Agreed... although x86 port for Solaris from SPARC wasn't enough to keep Solaris alive and kicking, despite the huge advancements Sun had made with the kernel and filesystem etc.
