Low-level programing languages & kernels

A lot of the early "let's write our own operating system" thoughts were based on buying or renting (no really ! - "renting" at the time) extremely expensive hardware from a vendor and then being stuck with a "so so" vendor provided operating system to run on it. DEC machines from the vendor were running RSTS, VMS, TOPS-20 and so forth. So the various corporate LABs decided Hay! We have already paid big $$$ for the expensive hardware but now we can get more (speed? memory? disk? data processing options? etc) out of this insanely expensive hardware with a better and more flexible operating system to run on it. If I get better performance from the insanely expensive hardware I can justify buying even more insanely expensive hardware in the future !

Unix being C based was easier to port to new CPU architectures -- just make a C compiler on the target hardware that outputs the right assembly code and then assemble the assembly code into target hardware machine code. Of course there have always been pure assembly parts of Unix/*BSD/Linux etc - but (X% of the work) of porting Unix/*BSD/Linux to new hardware was easy.

So when planning for a new operating system ... you have to think about: What problem am I solving that has not already been solved today? Sure you can "recreate" a threads API in your new O/S/programming language/etc - but we already have threads. Where do you want to go today (tm)?
 
CShell said:
So when planning for a new operating system ... you have to think about: What problem am I solving that has not already been solved today? Sure you can "recreate" a threads API in your new O/S/programming language/etc - but we already have threads. Where do you want to go today (tm)?
Click to expand...
I call that "solutions in search of a problem" and kiddies today are infamous for going that route when trying to make their mark in the world.

c-shell...I haven't used that since my days hacking on a humble DEC Ultrix workstation. LOL
 
  • Like
Reactions: cy@
Beastie7 said:
You people underestimate how difficult writing an operating system is. Let alone a stable, performant one.
Click to expand...
Once I read some fun fact many of you, at least the "older" ones, may already knew:
Do you know why Unix is so stable?
Because the very first version was gruesome unstable.
 
sidetone said:
Now that I think about it, Redox is about where NetBSD was 10 years ago. Back then, NetBSD hardly had Wi-Fi, it lacked GPU acceleration then.
Click to expand...
NetBSD had a vastly more substantial kernel and abstraction layers than Redox does currently. It supported more platforms and architectures back then than the Rust language itself does today. But due to its heritage, it also had way more man hours committed to it by that point.

But arguably Redox has other interesting aims. And pragmatically, only x86_64 and aarch64 matter currently, so its still a really interesting project.
 
There'll be a need for a small size programming language for a basic Operating system, which is used to run another language for specialized tasks, such as Julia for math/science related tasks or programming languages intended for gaming. This is outside of the scope of FreeBSD.

All there is to solve regarding BSD is classes of vulnerabilities in the base system, which are missed through the languages used, thus modern languages intend to fix. It shouldn't be rewritten on a wide scale. If anything, a modern programming language which is largely C compatible, and integrates itself the way C++ does, replacing parts. So, no Rust in that, bc it's too different than C or C++. This potentially includes Cheri.
 
sidetone said:
There'll be a need for a small size programming language for a basic Operating system, which is used to run another language for specialized tasks,
Click to expand...
That's what BSDs (and Linux, and MacOS) already provide: You can use (almost) any programming language there is "upon" the basic system.

With Unix what an OS is was defined.
Any (practical useful) OS there is, in an abstract, general view, either is some kind of unixlike (which, when you factor out the completely otherwise goofed up UI (("shell") usage, et al) but see it from a pure technical point of view, also includes Windows), or is something specialized to provide some basics for (almost) "bare metal" usage, open to question if those can be called OS, which we are not talking here anyway.
There are, and have been studies, and teaching models about how, and what an OS has to be. They all turned out either somehow unixlike (minix was already mentioned), or as something not really practical usable.

As long as the concept of how machines work does not change (CPUs running machine code, data needs to be used in memory, and stored on mass storages), like they do for over eighty years, and maybe I'm wrong but I cannot imagine this will change in a midterm future (I cannot imagine a quantum computer laptop will come in mass production for the common user within the next fifteen years), so long I cannot imagine another (useful) definition for an OS but somehow unixlike. So long Unix is and stays reference definition.

Also one may define the "basic system" as bootloader, and kernel.
For those a language needs to be used that produces something computer hardware can deal with, which was machine code. (Again: As long as the machines do not change the way they are radical revolutionary.)

Particulary for the kernel performance (speed) is crucial. There is a very limited need for an OS that fulfills all, or many benefits, features, and safety wishes but being slow like an outbraked snail.

Plus the language needs to be mature enough to be practical usable, and as I said above, also possessed by enough programmers to realize the amount of code needed for a unixlike system within a practical time (five to ten years.)

So, that and the need for fast machine code brings us to the following selection of languages (as far as I know):
Assembler, C, C++, Rust, maybe D, (and maybe Lisp if we also consider Lisp machines, which are not that common today, anymore, but at least theoretically possible to build.)
Any other language not coming close to the speed, and spread of those, ain't worth a closer look to be seriously considered for programming a practical useable OS.

That summarizes to:
As long as the core concept of machines does not change, and as long as there is no other language that produces machine code at least as fast as the existing ones, all talk here sooner or later anyway leads to something somehow unixlike to be programmed in Assembler, C, C++, Rust, or maybe D.
As some here already said: That's what we already have (in several flavours.)
Anything else is of pure academic interest, but of no practical use whatsoever, open to question if it's worth to discuss it.
 
Maturin said:
That's what BSDs (and Linux, and MacOS) already provide: You can use (almost) any programming language there is "upon" the basic system.
Click to expand...
I meant a small sized programming language and minimal type of OS, as in Embedded or barebones.

You can already throw a specialty language like Julia on top of FreeBSD, another BSD or Redox.
Maturin said:
Also one may define the "basic system" as bootloader, and kernel.
Click to expand...
Closer, but not necessarily as minimalistic.

Maturin said:
Particularly for the kernel performance (speed) is crucial. There is a very limited need for an OS that fulfills all, or many benefits, features, and safety wishes but being slow like an outbraked snail.
Click to expand...
Hare is a small C like language for making a small OS. It uses qbe as a backend. However, parts of Hare are heavily under AGPL and it's a Linuxism. It's a good model for such a language to build a minimalist OS for those purposes. Qbe is under a permissive license, and it itself isn't a Linuxism. Hare provides a model to follow for a minimalist programming language for an minimalist OS, and qbe may be the way for that.

As for Minux, that would be the perfect candidate to fork to replace with a safer C programming language alternative which compiles native C. Redox is already the improved Rust version of it. It's a temporary successor of Minux, until then.

As for D, I read that it was intended to improve upon problems with C, but as revolutionary as it was, it doesn't do as good a job as more modern programming languages. D is in the C family. Also, Objective C, C# and others were intended to improve upon C.
 
Odin programming language was meant as a C substitute. Its meant to have a simpler build system, and a simpler syntax than C. C3's error handling has been described as better than its. Otherwise, Odin has improved features over C.

C3 was meant to be a safer replacement for C, but Zig is much better for that. It lacks safety features that Zig has. C3 is described as more user friendly. This language also seems to preserve the spirit of C. C3 has a smaller user ecosystem than Zig and Odin.

Perk is new and not widely known.
Perk seems to be mostly written in Ocaml, but then compiled into C, as its own programming language. It incorporates Lambdas, which is a feature of Ocaml. Perk doesn't have a license shown at this time.

So far, it looks like Zig is the frontrunner of these other C style substitutes.

Also:
 
sidetone said:
C3 was meant to be a safer replacement for C, but Zig is much better for that. It lacks safety features that Zig has. C3 is described as more user friendly. This language also seems to preserve the spirit of C. C3 has a smaller user ecosystem than Zig and Odin.
Click to expand...
C3, Not to be confused with 3c developed by a fellow student from my old university and UNIX group. (Now an OpenBSD developer maintaining TexLive which is an interesting bit of trivia)
 
DanamonNani1951 said:
I not use C/C++/Java/Rust/C# because is not secure or not optimize the pcs, I only use Vala/Swift/OPascal/Ada
Click to expand...
Interesting take. Vala produces C code, so it's indirectly coding for C. You've implied that it's more secure than other languages. While Vala may be more secure, how about auditing code already in C, whether other code was added/altered to already converted code? Also, you implied that Rust was not optimized for PC, as in it's slow?

Swift only makes sense for Mac, as while some of it is useful on opensource systems, some related components are only useful in a Mac. I bought a book for it, and while I knew it was from Apple and meant for Mac, I later realized, it wouldn't become mainstream for other operating systems. I'm aware that there has been a Swift port. Opensource operating systems are useful for programming in Swift. The model is that multiple computers on a LAN with opensource software are used to code, then this code is sent to a connected Mac computer for certain closed source applications.
 
In C, programmers can write both secure and insecure codes. Just as assembly languages / binary instruction sets. So secure or not is on programmer (intentionally including reviewers and testers) and hardware design. And even so-called "safe languages" are somehow translated into binary instruction sets to run. So translating "safe languages" into C is sane.

Hardware design can be secure and insecure, just like softwares.

Imagine a quite poorly designed hardware sharing same physical buffer for input and output, and completely forgotton to implement interlocks and collision controls. It's mutually insecure and softwares including firmwares cannot make it safe, as buffers can be overwritten while softwares cannot notice the fact. Even so-called "safe languages" cannot assure the safety / sanity.
 
For memory safe programming languages (MSL) in the C family, are Rust, Safe-C, and Safe C++ all there are currently? Zig is considered memory safer, but still not memory safe.

There's attempted extensions and implementations to existing C: TrapC, Memory Safe C Compiler (MSCC), Cheri, Fil-C.

Rust may be an answer for the next decade, at least for an Operating System. Still, a safe C based language would need to be based off of both Zig and Safe-C. The reason for Zig, is because it, like Rust, covers more than C does.
 
You must log in or register to reply here.
Back
Top