Skip to main content

Abstraction levels: from source code to machine

“High level” and “low level” describe the distance between what code expresses and the machine details a programmer must manage. They are neither quality scores nor automatic performance rankings.

One requirement at several levels​

Consider an observable requirement: increment the character code for a, then print b.

In Python, number, string and standard-output operations come from the runtime:

code = ord("a")
print(chr(code + 1))

In C, the program names the value type and calls a standard-library function:

#include <stdio.h>

int main(void) {
  char letter = 'a';
  putchar(letter + 1);
  return 0;
}

In assembly, instructions and conventions depend on the architecture and operating system. This Linux x86-64 excerpt places system-call arguments in specific registers:

section .data
  letter db 'b'

section .text
  global _start
_start:
  mov rax, 1      ; write
  mov rdi, 1      ; stdout
  mov rsi, letter ; byte address
  mov rdx, 1      ; length
  syscall

All three snippets express a similar result, but they delegate different decisions to tools or runtimes.

What a higher level can abstract​

Depending on the language and implementation, a programmer may delegate:

  • value representation and allocation;
  • memory management;
  • calling conventions;
  • exact processor instruction selection;
  • part of the portability work across systems and architectures.

This delegation can make intent shorter to express. By itself, it says neither how the program will execute nor how many resources it will consume.

Language, implementation and toolchain​

A source file does not turn directly into a processor action. It travels through a concrete chain: parsing, intermediate transformations, libraries, runtime, operating system and finally machine instructions.

For example, a JavaScript engine may parse source, produce an intermediate representation, interpret some parts and just-in-time compile frequently run parts. A C program is commonly compiled into object files, linked with libraries and loaded by the system. “Compiled” and “interpreted” therefore describe implementation stages, not an exclusive and permanent language property.

Performance: measure the actual chain​

An abstraction level cannot prove that a program will be “fast” or “slow”. The observed cost depends on the algorithm, language implementation, optimizations, inputs, memory access, input/output and hardware. A useful comparison fixes a workload and measures the same result in a documented environment.

Observable check​

For a web application you use, write a chain in this form:

source file → tool or engine → optional intermediate representation
→ runtime / system → processor

The check passes when you can:

  1. name at least one real source file;
  2. name the tool or environment processing it;
  3. distinguish transformation from execution;
  4. explain why this chain alone cannot predict performance.