Base CS from zero
From machine code to a language: multiple-choice review
Crux Multiple-choice synthesis across the unit: the assembler's one-to-one rule, why high-level languages exist, compile vs interpret vs JIT tradeoffs, the runtime, and the full source-to-execution pipeline.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at middle altitude — in the skySix questions that cut across the whole unit. Each one asks you to connect ideas from different lessons — the assembler’s one-to-one rule, what high-level languages buy you, how translation strategies differ, and what the runtime does — rather than to recite a single definition.
Goal
Confirm you can connect the rungs of the ladder: raw machine code, assembly, high-level languages, the translation strategies that bridge them, and the runtime and pipeline that carry your code all the way to the CPU.
Quiz
Completed
You write one line of assembly, ADD R0 R1, and one line of TypeScript, total = price * qty + shipping. How many machine instructions does each produce, and what does that reveal?
Heads-up Only assembly is one-to-one. A high-level statement typically expands to several machine instructions; the compiler chooses them. That many-to-one expansion is the whole productivity argument for high-level languages.
Heads-up Assembly hides nothing — one mnemonic maps to exactly one machine instruction. There is no folding or expansion. The high-level line is the one that expands to many.
Heads-up The CPU never understands a high-level expression. It runs only the individual machine instructions the compiler emitted; one expression becomes several of them.
Quiz
Completed
A team wants to ship the same program to both x86-64 Linux servers and ARM laptops. They consider distributing it as hand-written assembly. What goes wrong, and what fixes it?
Heads-up Human-readable text is not portable execution. Each CPU family has its own instruction set and encodings; x86-64 assembly must be rewritten in ARM assembly to run on ARM.
Heads-up Assembly is already CPU-specific machine-level text; there is no portable bytecode step in plain assembly. Portability comes from writing in a high-level language whose translator targets each CPU.
Heads-up The instructions are exactly the problem — assembly mnemonics name one CPU's opcodes. The portable layer is a high-level language, not assembly.
Quiz
Completed
A CPU-bound batch job runs for hours. The team can ship it as compiled C or as an interpreted Python script. Ignoring development effort, which runs the computation faster at run time, and why?
Heads-up Skipping the compile step helps development speed, not run-time speed. At run time the interpreter pays translation overhead on every statement, so CPU-bound work runs slower than pre-compiled machine code.
Heads-up Only the C program is pre-translated to optimised machine code. A pure interpreter never emits machine code for your program — it carries out each statement with its own code at run time, which is slower for CPU-bound loops.
Heads-up Language level does not set run-time speed; the translation strategy does. Both are high-level relative to assembly, but compiled-ahead-of-time C runs the CPU-bound loop faster than an interpreter.
Quiz
Completed
A Node.js service is slow for the first few seconds under load, then speeds up and stays fast. Which mechanism explains this, and is it a bug?
Heads-up A leak makes a service slower over time, not faster. The speed-up-then-stable shape is the JIT warm-up curve: hot functions get compiled to native code after enough calls.
Heads-up Caching source text would not change the run-time speed of the computation. What changes is that the JIT compiles hot functions to native machine code at run time after warm-up.
Heads-up Loading happens once at process start in well under a second. The multi-second ramp is JIT warm-up: hot code paths being compiled to native code while the program runs.
Quiz
Completed
A junior says 'the runtime is just another name for the operating system.' Why is that wrong?
Heads-up The runtime sits between your code and the OS; it uses OS services but adds language-specific services (GC, standard library, VM) the kernel knows nothing about. Two languages on one OS have completely different runtimes.
Heads-up Even compiled C has a runtime: libc, program startup that sets up the stack and calls main, and exit cleanup. The runtime is thinner in C than in Python, but it is always present.
Heads-up Your code runs at run time, but 'the runtime' as a noun means the support infrastructure shipped by the language implementation — GC, standard library, VM — not your own source.
Quiz
Completed
You click Run on a C program. Which ordering of the pipeline stages is correct?
Heads-up Loading cannot come first — there is nothing to load until the source has been compiled and linked into an executable. Translation and linking precede loading; runtime startup precedes your code; fetch-decode-execute is the CPU running it.
Heads-up Linking happens before loading, not after. The linker combines object files into one executable; only then can the OS loader read that executable from disk and place it in memory.
Heads-up You cannot link before translating — the linker combines the object files the compiler produced, so translation must come first. And runtime startup runs before your code, not after the CPU loop.
Recap
The unit is one ladder. Assembly names machine code one instruction at a time; high-level languages let one statement stand for many instructions and stay portable across CPUs; compilers translate the whole program ahead of time while interpreters translate statement by statement at run time, and JIT mixes both by compiling hot spots on the fly; the runtime (GC, call stack, standard library, VM) supports your code throughout; and the full pipeline — source → translate → link → load → runtime startup → fetch-decode-execute — carries every program to the CPU, which never knows what language it came from.