Search code examples
assemblyhardwareabstractiondevice-driver

Curiosity beyond abstractions: how is bytecode executed? how do device drivers work?


Everything I've seen on *nix has been a set of abstractions off hardware, but I'm curious as to how the hardware works.
I've programmed in assembly, but that's still only a set of abstractions.

How does a processor understand assembly opcodes (as bytecode)?
How do device drivers work (with an explanation at a lower level (of abstraction))?


Solution

  • Wow.... huge question! At the very root level the processor can communicate with the hardware through special instructions e.g. IN and OUT to I/O ports on x86 hardware and/or some form of memory mapped I/O regions.

    Different hardware then has very different protocols / rules as to how to communicate over these channels and in general will probably fail horribly if these rules are not followed. An example would be an output device that can only handle a limited number of transmits per second, so the driver needs to check whether the hardware is ready to send more data before trying to transmit anything. You also usually need to ensure that there are no concurrent attempts to access the same device, which is one of many good reasons why operating systems do not allow user mode programs to directly access the hardware whenever they feel like it.

    Why not have a look at the Linux source code to satisfy your curiosity?

    Linux kernel drivers

    Note that most of this is written in C, not assembly language. There's no strict requirement to use assembly language to write device drivers providing you have the instructions available to communicate with the hardware (which is true in C, but might not be true in some higher level languages).