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).
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 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 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)
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)
>> 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)
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.
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!)
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.
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.
Addison Lee also tend to seemingly employ many drivers who drive as if they're doing their best to kill you, themselves, and any cyclists or unwary pedestrians around them. Worse still, this activity is actively encouraged by Addison Lee's own corporate policy
Hey, That's unfair to C! If an OS is reckless enough to give a process memory when it asks for it, it should have no business worrying about what the process does with the allocation!
In all seriousness though, the language can't be held responsible for poor programming practices.
For any insecurities resulting from c code, blame the compiler!