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

In Assembly there's not going to be much insight on linked lists, B trees, arrays, etc.

Um...what?

In fact those don't even exist at the bit level.

They don't exist at any level. Data structures are an abstract concept that get implemented using available language features. You can create a linked list, binary tree, etc... using assembly just as readily as in any full featured programming language.

So if we realize that the closer we get to the architecture the lesser the abstraction gets, and that our [...]

It seems like you quickly got off topic and started ranting about something completely different than the title of this thread suggests. What's your point?

If somebody was writing an operating system, they would probably want to get away from the messy bit flipping, associated with the hardware, as soon as possible, and instead have some nice abstractions to program.

Also, by working with high level abstractions, if you wanted to port the operating system to another architecture, you would only have the messy hardware level stuff to rewrite.

This article has been dead for over six months. Start a new discussion instead.