Skip to content

Abstract program model

Matt Windsor edited this page Dec 4, 2018 · 2 revisions

The abstract program model lies in the Abstract.* modules, and represents an architecture-neutral, generic model of an assembly program. It differs from the language abstraction layer in that translation to the abstract form is one-way, loses concrete information, and allows analysis without carrying around language-specific modules.

Components

At time of writing, the abstract model has the following components:

  • Statements (Abstract.Statement): generally, single lines of assembly input;
  • Instructions (Abstract.Instruction);
  • Operands (Abstract.Operand): arguments to instructions;
  • Operand bundles (Abstract.Operand.Bundle): sets of zero, one, two, or more operands;
  • Symbols (Abstract.Symbol): these correspond to any and all assembly symbols.

Kinds

Each component in the model also contains a submodule Kind: this contains a transparent variant type enumerating all of the high-level kinds of component (for example, Abstract.Statement.Kind has productions for Label, Instruction, and so on). This is useful for quickly querying the vague shape of a component.

To get a kind from a component, use its kind function.

Flags

Each component also contains a submodule Flag, which provides a more concise way to query all of the component's Boolean properties. Generally, each is_* function on an abstract component has a corresponding production in Flag.t.

If a component doesn't have any flags, Flag will still exist, but be uninhabited.

The Abstractable interface

The standard interface for mapping from concrete, language-specific syntax onto an abstract component is Abstractable.S. This exposes a function abstract, which gets the abstract component; abs_kind, which gets the abstract kind, and the predicates has_abs_kind and abs_kind_in, which can be used for quick kind comparisons.

Clone this wiki locally