Typed Assembly Language
Neal Glew   Intel Research

Program Fragments
  Real programs are divided into fragments that are 
  separately compiled and later linked

  Secure code systems are based around downloaded untrusted
  code fragments that are linked into the running system

  Type checking requirements
  - type safety
      type-check and link-check implying that the linked
      program when run never gets stuck
  - separate type checking
      - type checking
      - link checking

  Typed Object Files
  - OF ::= (I_I, H, I_E)
    -- A partial heap
    -- An import interface
    -- An export interface

  Interfaces for now are heap types
    -- I ::= \Psi

  Typing Object Files

  Linking
    - internal labels alpha vary
    - linking combines the heaps, the exports, imports
      that are not satisfied by the other object file

  Typed Linking
    - all exports are disjointed
    - all imports are compatible with other import and
      exports.

  Safety of Linking
  Safety of Loading
  These two guarantees End-to-End Safety (E is not stuck
    for any E ->* E', where E is the loadable output)

  Abstract Types
  Object Files with Abstract Types 

  Extensions
    - abstract type constructors (templates)
    - handle fully abstract, partially abstract and
      concrete types in interfaces
    - handle subtyping fully
    - renaming of labels or type names, hiding exports, etc

TAL3
  Data Structures, adding tuples
  <t1, ..., tn>

  heaps: map labels to heap values, could be code blocks or tuples
	 of values

  TAL3 Operational Semantics

  TAL3 Typing

  Arrays
    - hard issues
      -- bounds checking
      -- allocating and initialising a dynamically sized area of memory
    - simple solution, use macro operations
    - dependent types
      -- singleton types: S(n) - value is always n
      -- array type: array(n, t)
      -- propositions: represent constraints between variables of interest
      -- typing tracks values too

