18 ms·
> Why can “we” write pretty good apps in languages other than C, but can’t write operating systems? Is talking to hardware so much different than talking to API
by eatbitseveryday 5y ago
> Why can “we” write pretty good apps in languages other than C, but can’t write operating systems? Is talking to hardware so much different than talking to APIs?
Operating systems are written in other languages, such as C++ and Rust.
One requirement is that a language must be compiled and thus cannot rely on a runtime. That excludes Go and Java.
The language needs to support direct memory manipulation.
The compiled binary cannot be emitting system calls since that binary IS the kernel. Thus the compiler must be told to not link or include standard libraries.
You need to disable certain optimizations like advanced vectorization extensions and red zone use on the stack.
There are others. Lots of specific control needed.
- ArbixMenix 5y ago>One requirement is that a language must be compiled and thus cannot rely on a runtime. That excludes Go and Java. Maybe I'm wrong, but I know that there exist CPUs made specifically to natively execute Java bytecode, so in reality if the hardware has a baked-in language interpretation it would be actually possible to write an OS completely in Java
- bluGill 5y agoTrue, you can design a CPU for anything. However a OS that depends on such a CPU is not portable to anything else, and can't easily run most programs that people depend on (emulators are possible, but not easy). Also most CPU advances haven't gone into such a thing and it is tricky to apply those advances while also providing what the language needs. None of this is impossible, but it makes such CPUs in todays world of questionable value. Note that you can port any OS written in C to such a CPU with "just" a new compiler backend and a few drivers. Your OS won't take advantage of the features the CPU provides, but it will work.
- 3836293648 5y agoEh, can you really properly implement a CPU without interrupts? I wouldn't categorise anything in that space as a driver
- bluGill 5y agoGood point. I assumed there was some form of interrupt system, but not all CPUs need to have it, and lacking that your OS choices will be limited.
- gpderetta 5y agorunning java bytecode natively is neither necessary nor sufficient as you can compile java to any other native ISA, but you do still a relatively heavy runtime for GC. Having said that, there have been OSs written in languages with heavy runtimes, even GC.
- pjc50 5y agoARM "Jazelle" was capable of this, but it required a C implementation of a JVM. Any GC-dependant language has this problem.
- pjmlp 5y agoPlease find the C code here, https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...
- matthewaveryusa 5y agoThis is why rust is so exciting: it's the first new language that's graduated from toy-language space we've seen in a while without a runtime. (python, ruby, go and typescript-nodejs are the other graduates I'm thinking about.)
- pjmlp 5y ago> That excludes Go and Java. Only for those that cargo cult against using them. https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory https://developer.arm.com/solutions/internet-of-things/languages-and-libraries/go https://developer.arm.com/solutions/internet-of-things/langu... https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ https://www.aicas.com/wp/products-services/jamaicavm/
- MauranKilom 5y agohttps://xkcd.com/801/ https://xkcd.com/801/
- eatbitseveryday 5y agoI was answering the question in a general sense for the more prolific operating systems and on generic commonly available general-purpose processors. Yes one can implement a CPU that natively executes a runtime for a high-level language, make your own ASIC, or FPGA, etc. that does this. That is a more advanced response to the general question. Knowing the detailed points I mentioned will help understand why specialization of processors is needed to support other higher-level languages that do not meet the requirements I laid out.
- pjmlp 5y agoWhich just proves your lack of knowledge that those runtimes target generic commonly available general-purpose processors. None of those products use FPGAs or custom ASICs.
- eatbitseveryday 5y ago> just proves your lack of knowledge Tone is not needed. For TamaGo, it seems to allow developers run their application, not build an OS on the hardware. But I have not played with it, you are right. > TamaGo is a framework that enables compilation and execution of unencumbered Go applications on bare metal The environment does not seem to allow building a generic operating system [1]. F-Secure ported the runtime itself to boot natively. But please correct me. > There is no thread support The environment you run in is specifically curated for Go applications, such as the memory layout. I'd call this an "appliance" rather than enabling Go to be used for full-fledged generic operating system implementations. [1] https://github.com/f-secure-foundry/tamago/wiki/Internals https://github.com/f-secure-foundry/tamago/wiki/Internals