# Design Goals

These overlap a bit and will be refined as they develop, so bear with us :).

## Easy to Inspect and Manipulate with Commodity Tools

ZIP, bitcode, human-readable metadata, etc.

We provide new tools to operate on the format,
but the format is designed to be easily created, inspected,
and consumed for the cases our tools don't cover.

This is important for our own sanity, but also to ease
adoption and construction of tools interacting with the
format. More fundamentally, it is important to reuse good
techniques when they exist, e.g., compression, archiving,
file search, etc.

## Completeness

Software in this format is captured in sufficient
completeness that it may be executed by the ALLVM Execution
Engine without additional code components.
We also encourage the inclusion of key resources necessary
for execution, such as configuration files.

This has important implications regarding dynamically
linked libraries:
_all the libraries used by an application must be included,
directly or indirectly._
For ease of generation, updating, and analysis modularity,
and also to keep executable sizes reasonably small,
we encourage shipping these as separate ALLVM format files,
with linking deferred until run-time.

## All Code is in Rich IR Form

In order to facilitate analysis and transformations across
software boundaries (as well as after shipping),
all code in a system must be provided in virtual instruction
set format. In particular, code traditionally shipped as
native machine code must be in LLVM bitcode format.

For now this means code using assembly for any reason
is not allowed, including the use of inline assembly
as well as standalone assembly files.

This is likely too strict a requirement for all uses,
and mechanisms for handling those will be provided
in later versions of the format.

## Dynamic behavior is Statically Predictable

**THIS GOAL IS UNCLEAR AND VAGUELY STATED: MAKE THIS CONCRETE.**

(As much as possible!)
Software requiring this is encouraged to evalute if it
really needs the flexibility, and if so may elect to
indicate this need with a flag.

## Isolated-By-Default

While security is not a primary goal of the file format or core execution
engine, ALLVM systems should _enable_ the implemenation of secure systems
enforcing higher-level security policies.
Moreover, to enable and encourage aggressive
full-software analysis and transformations (such
as partial evaluation and full-system optimization) the behavior
of the software must be constrained to the extent possible.

How this is most naturally described for software
is yet to be determined, but for now includes:

- not being able to execute arbitrary code
- no self-modifying code
- JIT'd code must be generated by the ALLVM JIT or an "approved"
  language JIT, e.g., a JVM, .NET or other language implementation
- limited file system access
  - provided assets are available read-only
- All other data sources declared explicitly as input to the software

## Reproduction and Caching

Packages and components within an ALLVM file are described using identifiers
that uniquely describe their derivation tree. This is important for use in
reproduction, caching, and reproducion-with-transform
operations.

The purity model of these derivation trees is not yet determined,
but for now it should be expected to be strong in theory,
but in practice assume it's weak. **AGAIN, THIS IS VAGUE AND NEEDS
TO BE MADE CONCRETE.**

## Simple by Default

Capture the majority of use cases with what's simplest;
introduce complexities only if needed and to the minimal extent necessary.

## Suitable for Analysis and Transforms

The ALLVM format should enable sophisticated compiler analysis and
transformations across arbitrary software boundaries, including
application/library, application/OS, OS/device driver, and process/process.
Some of these fundamentally must be done after shipping, but can be done
offline, e.g., specialization of applications and the OS, or
autotuning of a software stack, both of which can be done at _install-time_.
Others are fundamentally _dynamic_, e.g., OS/device driver for
dynamically loaded drivers, or process/process for the common case of
distributed systems configured at startup time.

These fundamental constraints imply that the ALLVM file format must enable
install-time, run-time, and potentially idle-time techniques to be applied
_across arbitrary system components_. This directly motivates the need for
_all_ software to be available in IR form, stated above. It also motivates
the need for ALLVM tools that can operate across arbitrary software
boundaries.

### Associating and Storing Analysis Results for Software

### Offline Compiler Techniques

### Online Compiler Techniques
