I/O Design Considerations

.

Need to support all the basic source-code paradigms using syntactic sugaring: upcalls, downcalls and message passing on pre-defined channels.

Formatted I/O requires abstract data type defintions.

I/O paradigm should allow one piece of source code to specify both the sender and receiver or client and server or master and slave.

I/O should be flexible, from serialisable over untyped, one-bit networks, to disappearing and being optimised across when modules are merged. Data conservation, transaction scheduling and flow control should be intrinsic.

I/O should map well onto hardware/software boundaries.

  • Software calls hardware with custom instructions
  • Hardware calls software with interrupts.

    We will stick with the conventional re-use discipline that I/O crosses section boundaries with a section being the granule of re-use.

    Let's build-in blocking, synchronous, exactly once IO semantics.

  • I/O error requires reboot.
  • Add the other usual semantics and recovery using I/O libraries.

    I/O is peer to peer over staticly wired channels.

  • Provide a standard router in the library to provide multi-way communication or dynamic routing.

    • Home.           SRG Talk. 12 March 2003. DJ Greaves. www.cl.cam.ac.uk.