In Assembly there's not going to be much insight on linked lists, B trees, arrays, etc.
In fact those don't even exist at the bit level.
Sure, they help solve some problems from all the way up to your compiled language syntax, but such symbols don't exist in machine code, which is logically simple, just, and basic in bulk of operations in the bit level(i.e. move this here, add this using two's complement, return this, compare that, do this if that, etc.).
So if we realize that the closer we get to the architecture the lesser the abstraction gets, and that our higher level data structures convert back to basic just machine instructions once they've solved some of our problems, why not just go bare basics and accomplish the implementation of these high level data structures more confined to the architecture itself, since, ultimately, that is what happens to our linguistics after we press F9?
If I were to right now develop a kernel keeping in tune with the underlying architecture, rather than being secure that my linked library invoking driver called subroutines and APIs right underneath my symbols are translated perfectly in to executable format images and/or specific file extensions I would expect to worry about the chip's implementation, not the behavior of APIs, drivers, and other platform handling modules and services, hence, I'd worry more about how my code is working directly, and I'd focus more on the bare basics of programming.
That is operating system development, as the only thing beneath me is mostly going to be hardware.
If I were to continue on being abstracted of the hardware by dozens of services, driver invoking libraries and APIs, and other combination of tools, utility software, compiling and linking software, and perfectly designated methods to invoke one thing on to the other, I'd eventually become so abstracted from the actual implementation of the architecture by the operating system as a whole, and eventually wouldn't know what I'd be writing code for due to such bloating abstraction from what code is really doing.
For example, I am not setting a pixel on the window system's client area on a GUI with my code I am calling a method through a binded language with a compatible language compiled library that will invoke a driver that will access a service that have a kernel handle everything for me ever so precisely through an executable image. How am I doing the full work though?
Edited 3 Years Ago by Clan Onion