Yes you have it wrong.

The interpreter does nothing unless it has a script to interpret. The script tells the interpreter what to have the hardware do and the interpreter passes those instructions along to the hardware (or another software layer).
In fact there may be several layers of software between the user and the hardware.

hardware
firmware (or bios)
driver
kernel
app (which may be compiled binary, script with interpreter, or combination)
user

This shows at least 4 layers of software (and can easily be more) between the user and the hardware. Each layer is software, by definition, that talks to the next layer, and communication can go both ways.

Java and Javascript are very very close. If you write Java code, it can't run in the JRE(JVN) w/o 1st being compiled. If you write Javascript, it cannot be compiled, it needs the JRE interpreter (or some javascript interpreter).

So to me, the stuff in JRE/JVM is the "software", then you write script that directs the software what to do. I just don't see how some plain text file can be software.

Actually, "Java" and "JavaScript" are nothing like each other. But, "a whole lot of crazy ways to run JavaScript" have certainly been developed, including "just-in-time binary compilers."

There is also a P-code style system called "WASM."

Not necessarily true. Most C, C++, etc programs are compiled into binaries.
Those binaries are run by the kernel directly. However, the firmware which actually manages the hardware directly is mostly compiled from C and then loaded onto the hardware, so in that respect the hardware is mostly directly managed by code compiled from a C program

While it is true that most others do not run on bare hardware (that is the task of firmware and drivers) they do run at the lowest level available to the user space, and that is directly on the kernel.

Almost everything in userland is actually in contact with the kernel which still usually has at least a driver and firmware between it and the actual hardware.

A regular compiler condenses the free form language text into intermediate tables which show logic flow and memory locations. Then it goes through its intermediate tables and generates strings of machine code which it pastes together into a workable program.

An interpretive compiler condenses the free form language text into tables which show logic flow and memory locations which are called byte code. Then the interpreter goes through the table of byte code and feeds the CPU strings of canned machine code in the order dictated by the byte code. The interpreter simply acts as the last pass of a regular compiler.

The only difference between a regular compiler and an interpretive compiler is that the regular compiler throws away its intermediate tables and saves the generated machine code and an interpretive compiler saves the intermediate tables and does not save the machine code.

There are actually many ways to do it, as determined by various language-compiler switches. If you want, a binary compiler can produce an entirely stand-alone, entirely "statically linked," executable which contains all of the binary programming that the program needs to run, without any reference to anything external. Of course, this executable file will be large. If you choose to presume the prior existence of a system resource like "glibc," it will be smaller. But, either way, no part of the language-processing system that was used to create the software needs to be present on the system that subsequently runs it: as I said, the software "stands alone."

"If your objective is to create The Linux Kernel,™ or 'glibc' itself," then obviously these concerns are of profound importance to you.

Otherwise, it probably doesn't.

In today's world, with a ridiculous surplus of both RAM and CPU-power, we have plenty of options that simply didn't exist ... (yes, I was there) ... twenty or thirty years ago. We simply "didn't have the chips, yet." Now, we can build things – even massive things like Facebook – using language technologies that are purely-interpreted. The "preliminary steps" can be completed so rapidly that they simply do not matter, and the "runtime interpreter," whatever it is, can now be made so efficient that it also simply does not matter anymore.

The implementors of these "interpreted systems" might also have done a lot of the leg-work for you. For instance, "PHP" contains plenty of "built-in" features which actually carry a pretty heavy weight of "runtime implementation," as you can see for yourself if you navigate their public source-code repositories.

If your "pure binary" program wanted to do these things, it would necessarily have to do ... what the PHP implementors already did for you as they built their "pure binary program," which they called "PHP." If you use their system, and if you accept the minuscule "overhead" of doing so, you can cover a whole lot of otherwise-maybe-messy territory very reliably, and very quickly. There's definitely something to be said for that.

It is only you (human being) who need to distinguish readable from binary, it is not important at all for a computer.

Are you trolling?

I can still remember using BASIC on mainframes. That was (usually) an interpreted language. It differed from some others in that most OS's had a closed environment within which you wrote and ran BASIC programs rather than writing them in a freestanding editor. Each line of the program was interpreted by BASIC and then executed, but I have no idea whether the line was actually translated into machine code or whether BASIC carried out the execution itself as Python or bash would. On one computer that I used (I think it was a Prime) you had the option of compiling a BASIC program. Then you had a machine code executable which you could run outside of BASIC altogether. But I think that was unusual and I don't know how it related to what the BASIC interpreter normally did.

#1 I do not know of a single interpreter that works that way. Can you provide an example. It is unclear to me where you are getting this idea, and I do want to understand.

#2 BASIC interpreters that I worked on never created machine code. They interpreted BASIC source code line by line and called interpreter functions against the objects to execute the BASIC program. The PILOT interpreter I built (in 1983 I believe) worked pretty much the same way, with a different flow and functions. NONE of the P-CODE compilers I worked with generated machine code at any point.

Some of my hobby programs are interpreters and compilers.

An interpreter is a loop around a large switch statement. The switch statement selects the appropriate machine instructions for each "instruction" in the intermediate code. The loop iterates according to the program's dynamic control flow.

A compiler is also (effectively) a loop around a large switch statement. The distinction is that the loop iterates over the program's static instruction sequence. The dynamic sequence is deferred to the CPU running the generated machine code.
Ed

2 members found this post helpful.

I worked first on an HP-2000 Access computer which had built-in interpreted BASIC and no other available language. Then, I moved on to an HP-3000 computer which had both a BASIC interpreter and a true compiler. (Annoyingly, the new version of BASIC was not fully compatible, and in many ways less powerful.) The 3000 had about a half-dozen compilers from APL to RPG to COBOL, and later Pascal. Curiously, I never saw C or C++.

Every interpreter always begins by "parsing" the source code to create an internal data structure (the "AST") which represents it. This is then further processed into some data structure which then drives the interpreter's runtime engine.

The key feature of a compiler is that it produces some kind of file that can be executed – by some means – when the original source-code that produced it is now nowhere to be found. (Commonly, a runtime library is required. For instance, practically nothing in the Linux world can run without "glibc.")

I think the C runtime, such as the one you have on Windows made for VC++ programs, is just a glue between your executable and the OS. It isn't a retranslator where it translates the EXE into something runable by the real CPU.
I am not sure but I think it contains functions for memory allocation and deallocation. I imagine that it contains window creation related and program exit related stuff as well.

The file names and size varies quite a bit. For example, msvcirt.dll is 58.5 KB. There is a few versions of them.

For Linux systems, the filename is different glibc_something or other but probably it has a similar function to the VC version.

The outputted executable is just a Windows specific file or for Linux, it is of the ELF format.
It contains some info in the header but after that, I’m sure it contains x86_64 instructions that go directly to the CPU.

Originally Posted by Linux_Kidd View Post
Java and Javascript are very very close. If you write Java code, it can't run in the JRE(JVN) w/o 1st being compiled. If you write Javascript, it cannot be compiled, it needs the JRE interpreter (or some javascript interpreter).

So to me, the stuff in JRE/JVM is the "software", then you write script that directs the software what to do. I just don't see how some plain text file can be software.

I understand the point that he is trying to make however, I consider the source code as software.
The executable is also software, however, it is in a compiled form.

Like I said before, there are 3 categories:
1. software
2. data
3. hardware

The software category would have all assembly source code, all high level language code, it might be intended to be compiled to an executable, it might be compiled to some intermediate virtual CPU/OS wrapper the way Java does, or maybe the compiler is the compile and run on the fly (PHP, Perl, Lua, Ruby).

Combining these two statements (= discussed with my wife):
As far as I see from this point of view the source files (of any language) are not executable by themselves, therefore they are not software => they are all must belong to group 2, data or better to say information.
The executable code (which is actually processable by the hardware) is produced by another software (most probably by a compiler) using some additional information. It would be only the thing which belongs to group 1, software.
But if you run a code in an emulator all the files which were software on the original hardware will be just data on the emulator. And all the byte code produced by java, perl, python and others are still just data.
You don't need to agree with it (with my wife).