
1
System-Specific Interpreters Make Megasystems Friendlier
MATTHEW SOTOUDEH,Stanford University, USA
Modern operating systems, browsers, and oce suites have become megasystems built on millions of lines
of code. Their sheer size can intimidate even experienced users and programmers away from attempting
to understand and modify the software running on their machines. This paper introduces system-specic
interpreters (SSIs) as a tool to help users regain knowledge of and control over megasystems. SSIs directly
execute individual modules of a megasystem in a
gdb
-like environment without forcing the user to build, run,
and trace the entire system. A prototype framework to help write SSIs is described in this paper and available
for download at https://github.com/matthewsot/ssi-live22.
1 INTRODUCTION
Ballooning user expectations have caused computer systems to grow in size and complexity over
time. Operating systems, web browsers, oce suites, compilers, and even websites are routinely
hundreds of thousands or even millions of lines of code across a variety of programming languages.
These megasystems are extremely useful, surprisingly dependable, and often free software. But
their sheer size makes it increasingly dicult for users and hobbyist programmers to understand
and modify them. Even compiling some megasystems, such as the Linux kernel, can be a surprisingly
challenging task. Such barriers represent an unfortunate bottleneck through which even reasonably
motivated and skilled users are prevented from understanding and exercising control over the
software that has become necessary for their daily lives.
This paper proposes the development and use of system-specic interpreters (SSIs) to help users
understand and modify portions of such megasystems. The key insight is that, from the perspective
of any given module of the larger system, the rest of the system exposes a domain-specic language
in which the module is written. Directly building an interpreter (the SSI) for that language allows
the user to run individual modules, les, and functions without having to wait for the system to
build, construct inputs triggering the code in question, or insert tracing code.
In fact, programmers already build such SSIs informally in their heads when attempting to
understand megasystems. We usually start at some interesting part of the code, e.g., a particular
device driver, and read it without knowing exactly how it is called by the overall megasystem or
what all of the functions it calls do. Over time, an informal mental model of this interface between
the module and megasystem is formed to enable such underconstrained reasoning.
Our key idea is to formalize and mechanize this mental model of the interface between the module
and the rest of the system. By giving users the tools to formally specify (as an SSI) their previously
informal model of the system–module interface, the cognitive burden of remembering a large
model is reduced. Executing code against this model via the SSI helps users nd inconsistencies or
inaccuracies in their mental model of the system.
We describe a framework that makes writing SSIs easier. The key idea is to separate imple-
mentation of language-level syntax and semantics from system-level syntax and semantics. Once
written, SSIs simulate execution of a module in isolation, similar to a unit test. The user interacts
with the SSI’s
gdb
-style interface to trace and modify intermediate states of the execution. After
modifying the code, the SSI can be re-run to check if the modication had the desired eect. By
directly interpreting the specic code that the programmer cares about, SSIs are a rst step towards
bringing the power of live programming and REPL environments to bear on the unique challenges
of lower-level systems code.
Author’s address: Matthew Sotoudeh, Stanford University, Stanford, CA, USA, sotoudeh@stanford.edu.
arXiv:2210.09460v1 [cs.SE] 17 Oct 2022