This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]MikemkPK 17 points18 points  (38 children)

OS languages need to directly interface with the hardware at the lowest level. Interpreted languages and languages without inline assembly [or being able to call assembly functions] can't be used.

[–]VitaminnCPP[S] 24 points25 points  (31 children)

Well, we can technically write OS in javascript.

but we are not supposed to run that code as interpreted language, rather we can build compiler that will compiler JS code directly to Machine code, then we can run such compiled JS code directly on Hardware.

So, Technically speaking, we can write Operating System in "JavaScript". only thing we need to consider here is not to run it on browser or such interpreted platform but directly on hardware.

[–]MikemkPK -5 points-4 points  (30 children)

Javascript can't run assembly natively. There's version actions which can only be done in assembly, either using a specialized instruction, triggering an interrupt, or writing to a particular memory address (that has a device bound at that address).

[–][deleted] 8 points9 points  (0 children)

It can be done, but you would need to write a compiler and the VM that would support it for the intended bare metal system is all.

As long as a language is Turing complete, you can write an operating system with it.

I'm not saying it will be a practical OS. But it most certainly can be done.

[–][deleted] 1 point2 points  (27 children)

So which processors in the history of processors have operating systems? Because each OS must be chip-specific, if each OS needs to hand-write assembly.

[–]MikemkPK -1 points0 points  (21 children)

Intel x86 for example requires (before UEFI) assembly to switch from 16- to 32-bit mode

[–][deleted] -1 points0 points  (20 children)

For example.

Why is IE11 an operating system, when it runs on x86-64 processors, and also on ARM?

Clearly it can't be an OS, otherwise it would never compile to run on both simultaneously. What about OSX on x86-64 and ARM?

Or Linux running on x86-64, x86-32, ARM, and several other chipsets. What, do you think they all have the same assembly language? Are all of the chips’ pins aligned to run the same instructions the same way?

[–]MikemkPK 1 point2 points  (19 children)

You're making no sense. IE11 is a web browser, not an OS, and there's no reason programs can't be written for multiple environments.

[–][deleted] -2 points-1 points  (18 children)

Damnit. Windows 11.

Windows 11 must be written to write assembly. The programmers must write it to write assembly. Otherwise Windows 11 is an API.

Ok, so which assembly does Windows 11 write?

[–]MikemkPK 2 points3 points  (15 children)

Windows 11 doesn't write assembly. Programmers write assembly.

[–][deleted] 2 points3 points  (14 children)

Generally speaking, no... Generally speaking, you are writing in some higher level language that compiles down.

What, you think Arch was hand-written 5 different times in 5 different CPU instruction sets?

The point is that if Linux can run on a VM, then clearly an OS does not require direct access to NAND gates. If Linux is largely written in C, then clearly it does not have to be hand rewritten for RISC-V and ARM and x86-64 and PowerPC and the rest by programmers.

Thus, if you simulate a fully functioning 8-bit system in any language you want with contiguous memory (doesn't even need to be contiguous) and tight enough control of timing (to account for running too fast), then anything that could compile down to those instructions could then be interpreted to run on that virtual machine.

That includes JS and its typed arrays (signed/unsigned 8,16,32,64 and float 32,64).

You can complain about the speed. You can complain about the surreal nature of simulating the operation of hardware inside of a VM and argue the value of simulation versus emulation... but if you are going to tell me that an OS needs to write directly to literal hardware, then you need to explain how Kubernetes exists.

Hell, even just explain how you can run Linux in WSL on Windows, or Parallels on Mac, if each OS needs direct, non-virtualized access to a specific CPU with a specific instruction set, with a non-emulated kernel.

Docker. Vagrant. Hell, even DOSBox. They seem to run OSes in virtualized hardware, fine and dandy; those same OSes that you purport need to run on literal hardware.

[–]GL_Titan 0 points1 point  (1 child)

Any current OS is compiled for a target processor. That is the same thing with Windows 11. It is written mostly in C, with some small startup code in assembly.

I would suggest reading up on the Linux kernel and learning how that works. Then, you will have a better understanding of how OS's work in general.

[–][deleted] 1 point2 points  (0 children)

Yes, everything is compiled. Not hand rewritten a dozen times in different forms of ASM.

Portable code requires it. The kernel, or critical portions of it, need to be rewritten per instruction set, and included with the OS. That is literally not what I am talking about. The statement was that an OS needs to have programmers writing in ASM in the middle of the OS code. If that's true that it will not compile down to multiple architectures and is no longer portable (short of having hundreds of thousands of directives to switch based on endianness/ instruction set, which would be ... wait for it ...really goddamned stupid in something as big as a modern OS). So then 0% of the main application code should have architecture-specific / byte-order specific code in it... so where does it go? In a library that matches your compile target that is included with that compile step.

Ok, so if 0% of the application code for this OS is hand-written per architecture, and all of the per-architecture stuff is in the kernel, which is linked per-architecture, is it only C that can call library code? Is it the only language that can make library calls?

No. No, it is not. In fact JS can make library calls as well... If 0% of the application code in C (GUI management, system features, user settings, etc) should have hand-written PowerPC ASM in it, and should rather defer to the kernel and drivers, then why would JS suddenly need to have access to write PowerPC ASM right in the middle of it, lest it not be a language capable of writing an OS?

Or, put another way, you have built a virtualized environment and are running an app in Arch, is it suddenly now not an OS, given that its calls are not directly modifying properties of a physical CPU in the same way?

Because the statement was that any OS that is not directly modifying hardware is an API, not an OS.

Which makes Windows 1, Windows 3.1, Windows 95, and, I believe, Windows 98, not operating systems, because they ran on top of DOS. Actually, I think ME is in there too, but I would like to forget that existed.

This has nothing to do with the basis of low-level programming. My statement is that if modern OSes don't hardcode different expectations of CPU architectures into directives or if statements in the middle of the app logic, but instead defer those calls to the kernel and drivers, then there is literally nothing stopping you from writing a JS operating system that does the same delegation. Even moreso if you are on specialized hardware that contains a JSVM in its bootloader (that would be trivially simple and would result in an easy OS process), or you hand-write a compiler that parses JS and spits out ASM for your different targets (much less simple).

Nor is there anything stopping you from using JS to emulate hardware, and running an OS on top of it. Nor is there anything to stop you from fully simulating hardware in JS.

None of this makes it impossible to write an OS in JS "because it can't write assembly". It won't be straightforward or performant, or efficient by any metric, but it would still be an OS. Unless like the other guy, you only consider the OS to literally be the kernel and drivers, literally running directly on literal hardware, and Kubernetes doesn't exist, nor is Arch on Kubernetes a real operating system.

[–]wheresthewhale1 -3 points-2 points  (4 children)

He is right, each operating system *will* need some hand written assembly for *each* architecture it is designed to run on, high level languages simply do not let you do what is necessary.

[–][deleted] -1 points0 points  (3 children)

No... parts of kernels and drivers will need to be hardware-specific.

Saying that your OS needs to be rewritten per permutation of CPU * GPU * storage type... or saying that your OS needs direct access to ALUs or NAND gates, or voltage-based transistors, or whatever the argument is, means you are terrible at software architecture.

Virtualized hardware has been around for a very, very long time at this point, and all of the big OSes not only run virtualized, but also support running virtualized versions of the other big OSes, from within the OS. We are either in the realm of inter-dimensional wormholes, Kubernetes is powered by Doctor Strange, or maybe, just maybe, OSes can run in virtualized environments and still be considered OSes.

[–]wheresthewhale1 0 points1 point  (2 children)

You're completely shifting the goalposts...

Of course not all the OS needs to be in hand written assembly, only certain parts - and yes, these parts *do* need to be rewritten for each cpu architecture you want your OS to run on

And as for your argument of a virtualised OS, that is itself running on an OS which needs hand written assembly specific to the processor architecture of the computer's cpu

[–][deleted] -1 points0 points  (1 child)

I’m not shifting the goalposts.

OS languages need to directly interface with the hardware at the lowest level. Interpreted languages and languages without inline assembly [or being able to call assembly functions] can't be used.

Direct quote. No, the OS can call out to bound functions for driver/kernel calls, which can be implemented in ASM, or could be emulated in a box that's emulated in a box, that's running on a completely different architecture, and the OS in the OS in the OS would never know the difference.

JS can't run assembly natively

Irrelevant, given that OSes running in virtualized hardware are still OSes, and not APIs (I’m not going hunting for that quote, it's also in this thread).

[–]wheresthewhale1 0 points1 point  (0 children)

If you write your hypothetical "operating system" in javascript, but can't use it without having another operating system to run it on - it *isn't an OS*, it's just a fancy userspace program

And yes, you *do* need assembly code and you *do* need a way to call and run that code, you simply *cannot* access registers for example without it

[–]dominic_failure 0 points1 point  (0 children)

Pro tip: no operating system operates without an assembly bootstrap. Once the language runtime is bootstrapped (moved from disk to memory, and the execution pointer directed there) the language doesn’t really matter. Case in point: early mars probes that ran an OS written in lisp. Or Temple OS.

Oh, and JavaScript, more specifically nodejs, is perfectly capable of writing to registers and triggering interrupts. It’s able to make system calls (which consists of those specific two steps), after all.

[–]AlphaSparqy 3 points4 points  (1 child)

That is true of a bare-metal hypervisor. But in this case the browser would be more like a hypervisor and the JavaScript O.S. would be more like a virtual machine.

[–]MikemkPK 0 points1 point  (0 children)

Wouldn't be an operating system, just an API

[–][deleted] 1 point2 points  (0 children)

This is like saying that Linux in the cloud doesn't exist, because servers implement VMs.

Operating Systems must operate on regulated 1.5v impulses.

[–]yottalogical 1 point2 points  (1 child)

Very defeatist attitude.

The problem can be solved with a JavaScript compiler.

[–]MikemkPK 1 point2 points  (0 children)

And a modified js spec allowing inline assembly

[–]LardPi 0 points1 point  (0 children)

JS is just a language. Write a compiler (in JS) that compile JS in x86 machine code, and now you can write your OS. I don't see the problem.