(1/14) The Line Between Hardware and Software: Instruction Set Architecture (ISA)
Do CPUs understand Javascript? How does Python run in silicon? Is there a machine language and how does it relate to a language like Rust?
Your guide to the boundary between physical and virtual.
(2/14) A computer processor (CPU) is the like the brain of a computer; it is responsible for performing calculations and executing computation.
Think of a CPU like the computer's: it processes instructions and instructs the system to enable it to run programs/applications.
(3/14) Let's say you've written a program. You've (probably) written it in a modern language like Python or Rust. These languages offer massive benefits, including being easy for humans to write, review and understand.
The problem: the are MUCH too complex for a CPU.
(4/14) The underlying computer science is pretty intense, but suffice to say that the CPU is manipulating circuits and transistors to make your computer work.
The CPU speaks in the language of electricity - something as illegible to us as programming languages are to CPUs.
(5/14) One of the great magics of computer science is abstraction, a process where solutions are found for simple problems, thereby paving the way for solutions of more complex problems.
Abstraction allows us to hide implementation specifics from the next layer of development.
(6/14) In this process, we use a series of intermediate languages, facilitated by specialized programs called compilers/interpreters.
Here's the appropriate level of abstraction: human written code (eg python) is compiled to machine language, which is then executed by CPUs.
(7/14) Machine language refers to the instructions a processor can execute, and therefore operates within the direct reference to the parts of the CPU.
For example, machine language uses registers - specific pieces of silicon within the CPU.
(8/14) The set of instructions/operations that define the boundary between computer science abstractions and physical hardware is called an Instruction Set Architecture (ISA).
Once code has been compiled to an ISA, it's passed into the CPU and executed as physical changes.
(9/14) ISAs are incredibly low level and not intended for/interpretable by humans. Just take a look at what the (incredibly important) RISC-V architecture looks like.
Even still, the ISAs are an important abstraction as the layer that provides the foundation for computing.
(10/14) There are many different ISAs out there, some far more relevant than others. While it's not too important to categorize them, the main distinction is CISC vs RISC architectures.
tl;dr CISC implements many specific operations, RISC hyper optimizes a reduced set.
(11/14) So let's return to the magic of abstraction: think about designing the language of the CPU without worrying about the specifics of how the instructions are implemented on the physical chip.
Once we've built that interface, we can implement it virtually.
(12/14) While ISAs are designed for hardware, they can also be implemented to run in software. This allows us to create virtual machines (VMs) - emulations of physical computers.
VMs provide isolated computing environments hosted inside of another computing environment.
x.com/LogarithmicRex/status/1574208089661747200
(13/14) Taking a step back, there is an important line in computing between virtual abstraction and real-world hardware. ISAs are the language the mark this boundary.
By virtualizing these ISAs as programs, we can emulate computers in software to create virtual machines.
(14/14) ISAs are not just relevant to how a program is communicated to a physical CPU, but also how a program is communicated to a VM.
Put simply: an ISA defines an instruction set that defines a computational environment, one that can be implemented in silicon or code.