Turing’s Theta Combinator
Linux is an interpreter
31–40 of 65 posts
Re: Linux is an interpreter
#32Everything is an interpreter?
Re: Linux is an interpreter
#33Isn't every OS an interpreter for machine code with kernel privileges?
No. The OS's software doesn't individually read each instruction and decide what to do with it. It passes it off to the hardware (CPU) which runs the instructions.
Most of the time. But sometimes, no. See ATL thunk emulation (last I checked, still alive in the windows kernel) and ntvdm handling of the BOP pseudoinstruction.
See also: Jazelle DBX.
Hell, on modern x86 processors, many “native” instructions are actually a series of micro-ops for a mostly undocumented and mostly poorly understood microcode architecture that differs from the natively documented instruction set.
It’s turtles all the way down.
Re: Linux is an interpreter
#34This article was painful to read because of all the misconceptions. A cpio archive is not a filesystem. Author uses initramfs, which is based on tmpfs. Linux can extract cpio to tmpfs. An archive of files and directories is in itself not a program. Just because something looks similar doesn't mean it's equivalent. Binary programs are executed on the CPU, so if there's an interpreter involed it's hiding in the hardwar…
Binary programs are executed on the CPU but the program file is an archive with sections, and only one of them is the program, usually, while the others are all metadata. The CPU isn't capable of understanding the program file at all. Linux has to establish the conditions under which the program runs, that means at a minimum establishing the address space in which the program counter lies then jumping to that address. The instructions for how to do that are in the metadata sections of the ELF executable.
Re: Linux is an interpreter
#35Earlier quoted context omitted.
No. The OS's software doesn't individually read each instruction and decide what to do with it. It passes it off to the hardware (CPU) which runs the instructions.
Most of the time. But sometimes, no. See ATL thunk emulation (last I checked, still alive in the windows kernel) and ntvdm handling of the BOP pseudoinstruction. See also: Jazelle DBX. Hell, on modern x86 processors, many “native” instructions are actually a series of micro-ops for a mostly undocumented and mostly poorly understood microcode architecture that differs from the natively documented instruction set. It’s…
Jazelle and micro-ops are not interpreters, they are executed in hardware.
Re: Linux is an interpreter
#36I think the article works better as a mental model than a literal claim. “Linux is an interpreter” feels wrong if you define interpretation strictly at the CPU instruction level, but it becomes more reasonable if you look at the kernel as something that interprets executable formats and environments (ELF, scripts with shebangs, initramfs, etc.). In that sense it’s less about instruction-by-instruction interpretation and more about orchestrating how different representations of programs become runnable. Maybe the confusion here is mixing those two meanings of “interpreter”.
Re: Linux is an interpreter
#37Earlier quoted context omitted.
> if we can't afford 1.50$/mo, then we aren't really professionals and are just coasting on real infrastructure subsidized by professionals This is a strange claim. Whether someone is getting paid or not to do something is what determines who is a professional, not whether or how much they're paying someone else. (And that's the only thing that matters, unlike the way that "professional" is used as a euphemism in Ame…
I think the sense of the word professional here is not as a boolean professional/amateur, but the sense of professionalism, the characteristic of taking business seriously, not letting personal matters intervene, and in this case, investing into tools. To put an example, suppose you hire a painter, and they show up with non-work attire, no ladder, no brush, they ask you to buy a can of paint for them and a brush. Com…
Nope. There's no broader debate. "Professional" means "X is getting paid for this", not "X is paying something in order for X to be able to do this". It's that simple.
> To put an example, suppose you hire a painter, and they show up with non-work attire, no ladder, no brush, they ask you to buy a can of paint for them and a brush. Compared to a contractor that bills you flat and brins their own ladder, has work clothing and shoes, an air pneumatic spray painter, a breathing mask. Who is more professional?
Literally meaningless. Are both getting paid? Yes? Then they are both professionals.
You can insist on using "professional" in a strained way to try to facilitate some attempt at being judgmental and gatekeepy, but "professional" means what it means. If you mean something else, then say what you mean and leave out the euphemisms.
Re: Linux is an interpreter
#38Earlier quoted context omitted.
No. The OS's software doesn't individually read each instruction and decide what to do with it. It passes it off to the hardware (CPU) which runs the instructions.
Most of the time. But sometimes, no. See ATL thunk emulation (last I checked, still alive in the windows kernel) and ntvdm handling of the BOP pseudoinstruction. See also: Jazelle DBX. Hell, on modern x86 processors, many “native” instructions are actually a series of micro-ops for a mostly undocumented and mostly poorly understood microcode architecture that differs from the natively documented instruction set. It’s…
Aren't all of them microcoded? Some years back root was achieved on a line of intel processors and new instructions implemented as proof of concept. There's an academic paper, citation not immediately to hand.
Re: Linux is an interpreter
#39Earlier quoted context omitted.
I think the sense of the word professional here is not as a boolean professional/amateur, but the sense of professionalism, the characteristic of taking business seriously, not letting personal matters intervene, and in this case, investing into tools. To put an example, suppose you hire a painter, and they show up with non-work attire, no ladder, no brush, they ask you to buy a can of paint for them and a brush. Com…
Nope. There's no broader debate. "Professional" means "X is getting paid for this", not "X is paying something in order for X to be able to do this". It's that simple. > To put an example, suppose you hire a painter, and they show up with non-work attire, no ladder, no brush, they ask you to buy a can of paint for them and a brush. Compared to a contractor that bills you flat and brins their own ladder, has work clot…
You can't just conveniently ignore that "professionalism" is a concept that exists and is pretty clearly what the original author meant based on context and content. Refusing to interpret things in the most plausible manner just wastes everyone's time.
For example the phrase "unprofessional professional" means a professional (ie getting paid) who is behaving unprofessionally (ie exhibiting a lack of professionalism).
Re: Linux is an interpreter
#40Earlier quoted context omitted.
Most of the time. But sometimes, no. See ATL thunk emulation (last I checked, still alive in the windows kernel) and ntvdm handling of the BOP pseudoinstruction. See also: Jazelle DBX. Hell, on modern x86 processors, many “native” instructions are actually a series of micro-ops for a mostly undocumented and mostly poorly understood microcode architecture that differs from the natively documented instruction set. It’s…
Jazelle and micro-ops are not interpreters, they are executed in hardware.
I believe only some parts of Jazelle are handled in hardware, though I don’t know if anybody has got their hands on any of the bits of the software side. I do know there’s documentation on handling unimplemented instructions.
I don’t know how I feel about micro-ops being executed in hardware - I mostly agree, but also, microcode updates exist…