How does machine code communicate with processor?

Question

Let's take Python as an example. If I am not mistaken, when you program in it, the computer first "translates" the code to C. Then again, from C to assembly. Assembly is written in machine code. (This is just a vague idea that I have about this so correct me if I am wrong) But what's machine code written in, or, more exactly, how does the processor process its instructions, how does it "find out" what to do?

Sell

I have some simulators at github.com/dwelch67 meecoate for example is a clean, simple, instruction set, I have both logic and software simulators. Although possibly not the most beautiful logic solution, it could/would work as hardware, but should also be quite readable for a software programmer to follow. Likewise the software instruction set simulator should definitely be readable to programmers. – Causal

that is really how it is done, the logic "looks" at some bits, and makes decisions from there. The reality is from the hdl comes long logic equations for every little thing. Kinda similar to a high level language becoming a longer list of assembly instructions that implement that high level program. – Causal

Find/borrow the book "Code" by Petzold. – Causal

Answer 1

If I am not mistaken, when you program in it, the computer first "translates" the code to C.

No it doesn't. C is nothing special except that it's the most widespread programming language used for system programming.

The Python interpreter translates the Python code into so called P-Code that's executed by a virtual machine. This virtual machine is the actual interpreter which reads P-Code and every blip of P-Code makes the interpreter execute a predefined codepath. This is not very unlike how native binary machine code controls a CPU. A more modern approach is to translate the P-Code into native machine code.

The CPython interpreter itself is written in C and has been compiled into a native binary. Basically a native binary is just a long series of numbers (opcodes) where each number designates a certain operation. Some opcodes tell the machine that a defined count of numbers following it are not opcodes but parameters.

The CPU itself contains a so called instruction decoder, which reads the native binary number by number and for each opcode it reads it gives power to the circuit of the CPU that implement this particular opcode. there are opcodes, that address memory, opcodes that load data from memory into registers and so on.

how does the processor process its instructions, how does it "find out" what to do?

For every opcode, which is just a binary pattern, there is its own circuit on the CPU. If the pattern of the opcode matches the "switch" that enables this opcode, its circuit processes it.

Here's a WikiBook about it: http://en.wikibooks.org/wiki/Microprocessor_Design

A few years ago some guy built a whole, working computer from simple function logic and memory ICs, i.e. no microcontroller or similar involved. The whole project called "Big Mess o' Wires" was more or less a CPU built from scratch. The only thing nerdier would have been building that thing from single transistors (which actually wasn't that much more difficult). He also provides a simulator which allows you to see how the CPU works internally, decoding each instruction and executing it: Big Mess o' Wires Simulator

EDIT: Ever since I originally wrote that answer, building a fully fledged CPU from modern, discrete components has been done: For your considereation a MOS6502 (the CPU that powered the Apple II, Commodore C64, NES, BBC Micro and many more) built from discetes: https://monster6502.com/

Imaginary

Answer 2

Machine-code does not "communicate with the processor".

Rather, the processor "knows how to evaluate" machine-code. In the [widespread] Von Neumann architecture this machine-code (program) can be thought of as an index-able array of where each cell contains a machine-code instruction (or data, but let's ignore that for now).

The CPU "looks" at the current instruction (often identified by the PC or Program Counter) and decides what to do (this can either be done directly with transistors/"bare-metal", or it be translated to even lower-level code): this is known as the fetch-decode-execute cycle.

When the instructions are executed side-effects occur such as setting a control flag, putting a value in a register, or jumping to a different index (changing the PC) in the program, etc. See this simple overview of a CPU which covers the above a little bit better.

It is the evaluation of each instruction -- as it is encountered -- and the interaction of side-effects that results in the operation of a traditional processor.

(Of course, modern CPUs are very complex and do lots of neat tricky things!)

Canonist

Answer 3

That's called microcode. It's the code in the CPU that reads machine code instructions and translate that into low level data flow.

When the CPU for example encounters the add instruction, the microcode describes how it should get the two values, feed them to the ALU to do the calculation, and where to put the result.

Vexillum

Although there need not be any such microcode involved at all on simple processors. I think that just a simple look at how the PC/FETCH/EXECUTE works would be a good start in this case.. – Canonist

microcode is something special of CISC architectures, where each instruction gets broken down into sequence of micro operations. There are also architectures without a microcode, executing the opcodes directly. All the x86 before the Pentium were like this. – Imaginary

@Imaginary CISC need not have microcode. RISC could have microcode. – Canonist

@Imaginary For a modern CISC CPU. There is nothing inherent that says this is a property of CISC, although it makes sense in many cases. Likewise, for RISC this is inverted. Hence "need not" and "could". – Canonist

The well known/popular cisc family, x86, uses microcode, others have (the 6502 had a form of microcoding), nothing says that risc cant, but because of x86 everyone seems to think that all processors are microcoded and they for the most part are not. Microcoding is just one solution just like putting a processor in your dvd player and having a way to update the firmware. you defer having to get all of the product perfect, some stuff is unchangeable but some stuff you can fix after selling/shipping the product. – Causal

@datenwolf: You have it kind of backwards. 8086 microcoded everything, even add reg, reg like this answer describes. Later CPUs like maybe 486 and definitely Pentium decoded whole x86 instructions to one internal thing that goes through the pipeline. (For Pentium, dual-issue in-order, add ecx, edx and add eax, edx could both go through separate pipes in the same clock cycle.) But more complex instructions like add [ecx], eax didn't get broken up, but couldn't pair and occupied the pipeline for more cycles). (Very complex instructions like lock cmpxchg were still microcoded.) – Then

@datenwolf: Pentium Pro (P6 family) was the first x86 able to break up instructions like add [ecx], eax into separate load / ALU / store-address / store-data uops (so it could schedule them separately in the out-of-order back-end, overlapping with work from other instructions). In x86 terminology, this is still not "microcoded"; the decoders produce those uops directly. A microcoded instruction is one where the uops are read from a ROM, when more than 4 uops are needed for one insn like rep movsb (memcpy). What is a microcoded instruction?) – Then

@PeterCordes: I saw that my comment from 10 years ago was a little bit ill informed, and deleted it. – Imaginary

Answer 4

Electricity. Circuits, memory, and logic gates.

_{Also, I believe Python is usually interpreted, not compiled through C → assembly → machine code.}

Geralyngeraniaceous

Answer 5

Many people start off by explaining "When you press a key on the keyboard, then...".

Lets talk backwards. There is something called "Microcode" which breaks down your machine instructions into CPU specific code. Instructions are fetched from RAM (where a bunch of 0s and 1s in voltages are already stored as instructions for the cpu) in a process called a fetch-decode-execute cycle. This is also where cpu clock cycles come in.

Now you might ask hey, I have an IDE, in the form of an executable. My IDE can take care of the compilation and all the hard work. Then how does the IDE start up?

An operating system has something called a loader that feeds the executable instructions to RAM (setting up what you call "voltages" in RAM as instructions). This in turn gets read by the CPU and translated into microcode which then gets fed into other components.

An excellent book - https://www.amazon.com/dp/1558604286

When you press a key on the keyboard, then - https://www.youtube.com/watch?v=rNl9ol_rPMs

Novice guide to fetch-decode-execute - https://www.youtube.com/watch?v=-IyB8hBkA9w

Tirpitz