$Id: design,v 1.3 2007/10/29 10:09:32 voelp Exp $

*****
This file discusses high-level choices in the design of the
hardware model.
*****

* Type-safe memory

  The current (07/03/29) model requires block_disjoint-ness
  proofs even for C variables of different type.  To build a
  type-safe memory model, functions read_data/write_data (in
  Abstract_Read_Write) could be ``lifted'' to versions that
  allow type-safe memory access (including type-safe writes)
  only.  Then the memory model (e.g. Linear_Memory) would
  have to use the lifted functions either explicitly, or by
  instantiating an additional theory parameter.  Type
  information could be stored in a function
    Address -> lift[Interpreted_data_type]
  that is adjoined to the memory state, or perhaps by using
  the (underspecified) to_byte/from_byte coding functions to
  keep track of it in memory directly.

  We will work with the current, not quite type-safe model
  until the block_disjoint-ness conditions turn out to be a
  problem in the automatic verification of real-sized
  programs.  If this happens, Hendrik T. will make the
  necessary changes to the model to provide a type-safe
  abstraction.

* Memory side effects

  With the introduction of linear memory, side effects of the 
  underlying memory have no longer the information that writes
  were across minimal page (4K) boundaries. Since we want to 
  address failures of writing a large data type across linear memory
  page boundaries where the last page maps to a device (e.g., the
  APIC), we decided to add a flag to side effects stating whether a
  the side effect is invoked as part of a multi-page access.
  An alternative solution would be to add an oracle to plain memory
  which decides whether side effects across page boundaries work.
  A second alternative would check whether a side effect
  produces an identical state and result with the intension that only
  identity side effects allow cross page accesses. To prevent cross
	page accesses a side effect (e.g., for the APIC) would then have to
  always modify the state (e.g., by flipping at every access an
  artificial bit in the state).

* Cross page flag vs. Unspecified splitting

  We currently use a special cross-page flag to detect misaligned
  accesses in device memory. Because the virtual-to-physical address
  translation may split a virtually contiguous part into physically
  discontiguos parts the side effect in the device memory is presented
  an access that may fulfil the alignment restrictions.
  
  Tjark proposed an alternative solution which requires no additional
  cp-flag and which (with a slight modification) solves two further
  problems: 
  - the compiler / hardware may split or combine accesses to
    smaller (resp. larger) chunks. 
  - upon a page-fault we must report the system state at an
    assembler-instruction boundary. In particular, we have to retry
    this instruction.

  Tjark's proposal was to use an underspecified splitting when
  translating the accesses of one memory model to the accesses of a
  respective lower model. When splitting, the accesses to the
  underlying memory may read and write more data than the original
  access as long as only the content of modified parts is modified.
  Writing the same content is possible and may happen in reality
  (e.g., unmodified parts of a cacheline are written to memory
  together with the cacheline). 

  By allowing both reads and writes and possibly atomic read-write
  pairs to appear in the set of accesses that such an underspecified
  split may produce we "might" be able to model the correct behaviour
  of a page-fault by reporting the instruction pointer of the last
  split access and by restarting with this precise access.


  
