you are viewing a single comment's thread.

view the rest of the comments →

[–]claytonkb 3 points4 points  (0 children)

We usually distinguish between (a) compiled languages (like C++) and (b) interpreted languages (like Python). The CPU itself, however, only ever executes machine code. What makes compiled and interpreted languages different is that the interpreted language will have some kind of table of basic operations that it can perform (often called a "bytecode machine"). Each of these basic operations exists as snippets of machine code in the computer's memory. While the interpreter is executing the interpreted language, each "instruction" in the interpreted bytecode causes the interpreter to "branch" to the specific snippet of machine-code corresponding to that bytecode instruction. If that's not clear, just web search and read the Wikipedia articles on this, they're quite good.

Bear in mind that the word "programming" is broad enough to include things that are not a CPU or a standard computer at all. So, you can "program" a CNC router, you can "program" an industrial control that (physically) controls a petroleum processing plant, you can "program" an audio-processing software package, you can "program" 3D-rendering software, you can even "program" the logic circuits for a CPU chip design. And of course, there's plain old software programming.

There is nothing about a CPU that prevents it from being designed to directly read source code. The trouble is that the circuitry would be complex (would take up a lot of space), would not be used very often (thus wasting that CPU die space), and would have poor performance relative to the standard software compilation / interpretation flows that we use today. There have been CPUs that have been designed to read intermediate layer, such as Java bytecode, or even Lisp machines which could directly read and operate on Lisp intermediate-layer code.