OSDev.org

bzt wrote:Programmers are wasting resources, they don't know how computers work any more. They just import a huge library, that's it.

Or they want or are asked to finish their code ASAP.

I don't think it's a bad idea to use libraries. But, yes, programmer nowadays don't seem to know much about low level. They do a lot of high lvel stuff, like Java, Javascript, Python (which I like, but anyway...), Perl, virtual machines, containers and such things.

Prof. Donald Knuth started some day publishing his code examples in MMIX, a virtual assembler language because he didn't want to write it in Java, C++ or similar. So I guess he likes if people learn the basics of programming (which is Assembler in this context).

Without Assembler most programmers can't understand fully stack, paging, interrupts, timers, I/O and many things more.

Greetings
Peter

I was thinking if the hardware and the underlying systems weren't this complex, perhaps the software engineers may be able to get a bit more power out of the existing hardware. Also, we would see more OS in the market other than windows & 1000 flavors of Linux. Programmers doesn't know low level because it's hard to understand. If it wasn't, more people would get into communities like this and we may be seeing more efficient close to the metal software. Also, speaking of interpreter bugs, it's actually safer in my opinion as soon as a bug is discovered, it can be easily patched. But what about hardware flaws like spectre & meltdown? We have to upgrade to a new hardware to be safe for sure. Yes, it might be harder to pull off, but if someone did it, it would be catastrophic.

Also, the interpreter systems may be made separate from core system services(which, as part of OS, trusted and written in binary) or another instance of the same, and the process and memory management can be done by he kernel, which may not be even documented. I don't know, maybe thus the underlying systems can be patched or changed without actually affecting the programs. Maybe implement something like paging in software, or even in hardware in simpler form to isolate between them..

We can go beyond and hide the core system files or memory from user and even from the interpreter, more like android work, but with better control and features. You can't easily hack into what you can't even see, even if you got inside, you don't know what's what or where. By then, it's patched. Also, it will be very hard for buggy programs that need admin access to run, can screw up the entire system if there is not a complete 'admin access'.

PeterX wrote:I don't think it's a bad idea to use libraries.

No, not at all! I did not wanted to suggest that.
I only meant, on bare metal you don't have any libraries, only the ones you write yourself. This is quite a big deal and unsolvable mystery for someone who has used libraries only in their entire life.

Cheers,
bzt

bzt wrote:

PeterX wrote: I only meant, on bare metal you don't have any libraries, only the ones you write yourself.

I'm not sure that's true. As a simple example, BIOS interrupts, which are very popular with some, are just a set of library calls. I don't think that writing everything yourself, constantly reinventing the wheel, is the most profitable use of a programmer's time.

iansjack wrote:

bzt wrote: I only meant, on bare metal you don't have any libraries, only the ones you write yourself.

I'm not sure that's true. As a simple example, BIOS interrupts, which are very popular with some, are just a set of library calls. I don't think that writing everything yourself, constantly reinventing the wheel, is the most profitable use of a programmer's time.

If it were only about profitable use of programmer's time, we all wouldn't write own OS but rather publish Linux distros I guess.

Greetings
Peter

iansjack wrote:I'm not sure that's true. As a simple example, BIOS interrupts, which are very popular with some, are just a set of library calls. I don't think that writing everything yourself, constantly reinventing the wheel, is the most profitable use of a programmer's time.

Come on, you know exactly what I mean. In freestanding mode there's no libc, no memory management, no shared library support etc. BIOS does not use standard ABI either, requires operating mode changes (to real mode and back again to protmode/longmode), you can't just make a function call to it. You need to implement a BIOS call wrapper yourself. These are frightening to programmers who are used to just link and make a call without understanding how that works, and there are fewer programmers every year who can come around. That's a fact, sadly.

Cheers,
bzt

pranavappu007 wrote: was thinking if the hardware and the underlying systems weren't this complex, perhaps the software engineers may be able to get a bit more power out of the existing hardware.

Hardware is so complex in part to get more power out of them. There was a time when CPUs were as fast as RAM. No caching was needed, possible, or even desired in those days. The CPU would request a byte from RAM and receive it the same cycle. Since there was no caching, there was no way to set it up, and, importantly, no way to screw it up. Reading and writing RAM worked like reading and writing any other kind of hardware.

Then CPUs got faster. RAM as well, but not as much as CPUs. CPUs started stalling on RAM cycles, and finally, a layer of caching was added. Then another. Then mainboard engineers screwed up cache implementations once too often, and Intel released their next CPU series on cards. Suddenly there were caches to configure, and if you screw it up, in the best case you loose performance, and in the worst case, no MMIO works anymore. Then CPUs hit the speed limit and started to get more and more cores on a single die, meaning that now, even a normal desktop OS has to take care of multicore (with lots and lots of cores), and caching has become an impenetrable beast. But all just to get more performance out of it.

Just one example. Pipelining, branch prediction, speculative execution, all are borne of the desire for more performance.

pranavappu007 wrote:Programmers doesn't know low level because it's hard to understand.

Programmers don't know this because they don't have to. You really never need to know what "int a = 1;" really means on the hardware level. It is enough to know that you created an object of type "int", by the name of "a", and gave it the initial value "1". Where exactly that object is stored only starts to matter once things go south.

nullplan wrote:

pranavappu007 wrote:Programmers doesn't know low level because it's hard to understand.

Programmers don't know this because they don't have to. You really never need to know what "int a = 1;" really means on the hardware level. It is enough to know that you created an object of type "int", by the name of "a", and gave it the initial value "1". Where exactly that object is stored only starts to matter once things go south.

Yes, for many areas of programming that's correct. But there are many fields where it's useful to know some low level details. Not only kernel dev. But also libraries, sometimes applications (for example games, system tools) and to some extent networking. OR when you deal with lists, pointers, stack, float point math, multiprocessing, etc.

PeterX wrote:

nullplan wrote:

pranavappu007 wrote:Programmers doesn't know low level because it's hard to understand.

Programmers don't know this because they don't have to. You really never need to know what "int a = 1;" really means on the hardware level. It is enough to know that you created an object of type "int", by the name of "a", and gave it the initial value "1". Where exactly that object is stored only starts to matter once things go south.

Yes, for many areas of programming that's correct. But there are many fields where it's useful to know some low level details. Not only kernel dev. But also libraries, sometimes applications (for example games, system tools) and to some extent networking. OR when you deal with lists, pointers, stack, float point math, multiprocessing, etc.

There's also the fact that things *will* go south. You *will* write code with bugs in it, and the exact effect of those bugs may very well depend on the details of lower levels of the abstraction stack. And even if you're superhuman and your code is pristine, the people that wrote your C library, your OS, the HDL code that is used to create your CPU, etc, *will* write buggy code, and when you run into bugs in lower abstraction layers, those bugs will by definition depend on the details of those layers.