2

Do interpreted languages such as Java and Python need an operating system to work?

For example, on a bare-metal ARM microcontroller, can an interpreter be installed such that we can have both compiled code such as C, and interpreted code such as Python working together, Or is an OS needed to support this?

Robert Columbia
  • 6,313
  • 15
  • 32
  • 40
Engineer999
  • 3,683
  • 6
  • 33
  • 71
  • 1
    I suspect the answers to "Can an interpreted language theoretically run on bare metal? Can Java run on bare metal? Can Python run on bare metal?" are yes, no, and no respectively. So the answer to your question depends on the degree of specificity. – Kevin Feb 26 '19 at 15:22
  • Java is not interpreted language! – Vadim Feb 26 '19 at 15:24
  • 1
    @Vadim Nor is it a compiled language. Java byte code is platform independent. – Engineer999 Feb 26 '19 at 15:27
  • Anyway Java is not interpreted language. JVM is not an interpretator. And JVM code is compiled, platform dependent and written on C – Vadim Feb 26 '19 at 15:37
  • @Vadim then in truth everything is interpreted, and also nothing is. Nowadays it is a question of *degree* - modern *processors* sometimes "interpret" their architecture's machine code into its own internal representation. – Robert Columbia Feb 26 '19 at 17:46
  • It is out of topic to talk about basics - what is interpreter and what is a compiler... – Vadim Feb 26 '19 at 18:41

4 Answers4

4

Of course you can write an interpreter that runs on bare-metal, it is just that if the platform does not have an OS any run-time support the language needs must be part of the interpreter. To the extent in some cases that such an interpreter might essentially be an OS. That is if it provides the services to operate a system, it could be called an operating system.

It is not perhaps as simple as interpreted vs compiled. Java for example runs on a virtual machine and is "compiled" to bytecode. The bytecode is interpreted (or just-in-time compiled in some cases), rather then the Java source directly. In an embedded system, it is possible that you would deploy cross-compiled bytecode on the target rather then the source. Certainly however JVMs exist for bare-metal. Some support multi-threading through a third party RTOS, others either have that support built-in or do not support threading at all.

There are interpreters for cut-down subsets of JavaScript and Python that run on bare-metal microcontrollers. I am not sure about full implementations, but it is technically possible given sufficient run-time support even if not explicitly implemented. To fully support some of these languages along with all the standard and third-party libraries and frameworks a developer might expect, may require so much run-time support and resource that it is simpler to deploy and OS, so implementations for resource constrained systems are often subsets or have restricted libraries.

Clifford
  • 88,407
  • 13
  • 85
  • 165
3

Java needs a VM - virtual machine. It isn't interpreted, but executes byte code. Interpreted would mean grabbing the source in run-time as it goes, like BASIC.

When Java was new and exciting around year 2000, everyone thought it would be the next big general-purpose language, replacing C++. The syntax was so clean, it was "pure OO" and not some "filthy hybrid".

It was the major buzz word of the time. Schools stopped teaching C and C++. MCU manufacturers started to make chips with Java VM in hardware. Microsoft made their own Java "standard". Everyone was high on the Java hype.

Then as the Internet hype as whole collapsed in 2002, it took the Java hype with it. In the sober hang-over afterwards, people started to realize that things like byte code, VMs and garbage collection probably don't belong on bare metal systems.

They went back to using compiled C for hardware-related programming. Or in fact they never stopped, since Java never quite made it there, save for some oddball exotic architectures.

Java remained used only in the areas were it was suitable, namely web, desktop and mobile development. And so it got a second golden age when the smart phone hype struck around 2010.

Lundin
  • 195,001
  • 40
  • 254
  • 396
2

No. Some 8-bit computers had interpreted languages in ROM despite not having anything reasonably resembling a modern operating system. The Apple 2 is one example. You could boot the system without any disks or tapes, and it would go straight to a BASIC prompt, where you could write basic (no pun intended) programs.

Note that an operating system is somewhat of a vague term when speaking about these days - these 8-bit computers did have some level of firmware, and this firmware did provide some OS-type functionality like access to basic peripherals. In these days, what we now know as an OS was more commonly called a "DOS" - a Disk Operating System. MS-DOS is one of them, as well as Apple's ProDOS. These DOS's evolved into our modern-day operating systems (e.g. Windows 95 was based on top of MS-DOS, while modern Windows versions derive from a separate branch that was largely re-implemented with more modern techniques), so one could claim that their ancestors are the closest they had to what we now call an OS.

But what is an interpreter but a piece of software?

In a more theoretical sense, an interpreter is simply software - a program that takes input and produces output. Suppose you were to implement a custom solid-state Turing Machine. In this case, your "input" would be the program to be interpreted, and the "output" would be the program's behavior. If "software" can run without an operating system, then an interpreter can.

Is this model a little simplified? Of course. The difference is a matter of degree, not nature. Add very basic user input and output capabilities (e.g. a TTY) and you have the foundation to implement all, or nearly all, of the basic functionality of a language such as Java byte code, Python, or BASIC. The main things you would be missing are libraries and whatnot that depend on things like screen manipulation, multiprocessing, and networking, but you could handle them with time too.

Robert Columbia
  • 6,313
  • 15
  • 32
  • 40
  • 1
    Pedantic point, but Windows 3.x was the last 16 bit Windows that required MS-DOS. Windows 95 was was a 32 bit OS in its own right. Before that Windows NT was also a true OS that became Windows 2000 before both consumer and business OS's were merged to become XP. – Clifford Feb 26 '19 at 16:57
  • @Clifford true, but you could still boot Windows 95 to a "DOS" prompt, and [Microsoft itself](https://blogs.msdn.microsoft.com/oldnewthing/20071224-00/?p=24063) mentions that " MS-DOS served two purposes in Windows 95: 1) It served as the boot loader. 2) It acted as the 16-bit legacy device driver layer.". – Robert Columbia Feb 26 '19 at 17:43
  • 1
    Many of the old 8-bit computers would boot to basic out of ROM and had their OS in ROM. These provided the same sort of standard interfaces to hardware and file system resources without having to load the program from a disc. The BBC computer ROM provided hardware agnostic OS function calls for much of the functionality associated with standard DOS calls. There are also freely available BASIC interpreters that are written in C and can be compiled onto bare metal processors. – uɐɪ Feb 27 '19 at 15:05
  • @uɐɪ true, but we are getting into the fine line between an "OS in ROM" and traditional firmware. That's why I mentioned the historical evolution of how modern-day OS's derive most directly from 1980's *Disk* Operating Systems rather than 8-bit firmware. Also, if your OS is in ROM, it's more firmly bound to the processor (not as easy to upgrade), so it lacks much of the flexibility of a modern OS. – Robert Columbia Feb 27 '19 at 15:12
2

No. See for example picoJava, which is one of several solutions for running Java natively. You can't get closer to bare metal than running bytecode on the CPU.

ewramner
  • 5,810
  • 2
  • 17
  • 33