How do binary numbers interact with the CPU and cause some action to take place?

Question

EDIT: Perhaps what I am misunderstanding is that when it is said that the code we type gets turned into machine code of 0s and 1s. If these 0s and 1s are the abstracted representation of their electric states, then I actually don't have a question (it is just amazing that a compiler can take English and turn it into a form that can impact the processor). If the compiler turns the code a file that contains literal 0s and 1s, then I don't understand the transformation steps steps that strictly occur between this file of literal 0s and 1s and the execution of the program (I understand how programs already in RAM are executed).

I have been researching for an answer to this question all day. I have read a lot about the computer's hardware and understand concepts like the clock, its different states that it "steps" through to execute a program, and (at a basic level) the compiler. I also know that the bits of each part of an instruction code are wired in a certain way so that it does what it is supposed to and the compiler takes the code we write and converts it to binary. But my question is this: how does the processor "understand" this binary (or machine readable) code.

In the computer there are no 0s and 1s obviously, and 0s and 1s are an abstraction themselves reprenting the presence or absence of electricity. So how does a 0 go in one end of the computer and a bit being off come out the other? I understand how this may work with input from the keyboard because I understand how computer peripherals work and get stored to some degree (the wiring underneath the keyboard accomplishes this as an extension of the wiring of the hardware that accomplishes everything that the computer does), but the compiler and the other (seemingly missing) piece of the puzzle that moves the computer to action seem to be a black box right now. Thanks so much in advance, always appreciate any responses.

One last time just to be super clear: I understand the compiler takes our code and converts it to 0s and 1s. That's great, but how does this 0 get interpreted, by a component and/or a process, that causes this abstraction (like the #0) cause one of the computer's bits to be in a different position.

Thanks so much once again. I have searched for hours about this question on this forum and other places and I can't seem to find an answer that moves past the: "yeah the compiler converts to 0s and 1s and those do some stuff". The how is what I am after.

Answer 1

CPUs have instruction sets, add two numbers, jump forward 3 instructions, if this is true run the next instruction, if not skip and instruction etc

https://en.wikipedia.org/wiki/Instruction_set_architecture

The 1s and 0s are stored in the memory of the computer and grouped together and read as instructions or data, ie run instruction number 3 or data ie take that bit of memory there and do some operations on it.

Essentially when you compile code you are turning it into combination of these very basic instructions which are stored on disc, loaded into memory and then run by the cpu.

Some of these instructions or areas of memory will map to pins on connectors to devices, such as a graphics card, or disc drive etc and their state, on or off will cause the device to do things.

Answer 2

A compiler operates at a logical level, not concerning itself with physical storage, but rather with groupings of 1's and 0's — several different kinds of groupings.  The first grouping is text files aka source code, and the second grouping is machine code.

Text is stored on disc, for example, as a sequence of bytes, where a byte is a group 8-bits that is ordered from most significant to least significant (or vice versa — that's up to the media;  each bit of course is physically encoded in the media as physically measurable values differentiating 1's from 0's).  Each byte represents a number: the number represents an ascii or UTF-8 value.  This is a logical encoding or mapping of logical characters into logical bytes — a layered encoding well above the physical encoding of bits in media.

Machine code is also a logical encoding of command operations to numbers — also well above the physical encodings of bits in media.  It can also be stored on disc as a sequence of bytes.

When the compiler recognizes a program's syntax according to the grammar of the programming language, it builds an internal object diagram of that program.  Later it traverses that object diagram in order to generate commands in machine code to instruct the processor to follow the steps of the program.

Machine code is designed to be easily decoded (at least by comparison to other encodings) — usually there's a first field that is an opcode field that tells the processor something about how to interpret additional fields of the instruction.  The compiler knows these encodings and generates them for the processor such that it will perform the given program.

Answer 3

But my question is this: how does the processor "understand" this binary (or machine readable) code.

It doesn’t. It’s turns numbers into other numbers and puts them different places based on still other numbers.

What those numbers mean is someone else’s problem. That someone sometimes thinks of them differently based on where they are. But they’re still just numbers. The processor doesn’t need to know what they are. Just how to transform them and where to put them.

So how does a 0 go in one end of the computer and a bit being off come out the other?

From a microphone or analog joystick being sampled or a keystroke at the keyboard, zero finds its way in through many different ways.

If that joystick has a 100k potentiometer in it you might think 100,000 values can come out. But if I’m sticking the value in one byte then only 256 values can come out. Because a byte only has 8 bits. This is called analog to digital conversion.

Another way is someone just types in a zero at the keyboard because they want a zero. They can do it hex, octal, ascii, heck even binary if they want to be silly. They know where they want the zero and they know what it will mean. Doesn’t mean the processor does. All it knows is what it’s supposed to do with it.

What we programmers do is use the rules that the processor follows blindly to get some useful work done. That might be letting you see and edit what you’ve typed on the screen before you put it on paper. It might be hearing what that zero sounds like when a sound card plays it on the system speaker.

What gives that zero meaning in it’s different places is often something called an encoding. If we’re talking about ascii (or UTF-8) a zero often means this is the end of the string. (Pascal strings tell you how long they are in the first byte. For them zero means a zero length string).

But not everything is encoded text. Some stuff is just data and it doesn’t follow any set pattern to tell you what it means. It will only be meaningful to whatever created it.

It is impossible to simply look at a zero and know what it means. You need to know it’s context. The processor is no different.

The really magical thing the processor does is copy that zero around faithfully. It doesn’t let it turn into a 0.3 when no one is looking like analog stuff does. That’s the real reason we use 1 and 0. It’s on or off. Anything in between is noise to filter out.

But it takes humans to make that zero into something humans care about. The processor don’t care.