
        OCCAM FOR ALL PROJECT : KENT RETARGETABLE OCCAM COMPILER (KROC)

                               WORKS IN PROGRESS

   Things that currently are in progress and have personnel allocated are
   indicated by *s to indicate approximate effort.

Multiprocessing (*****)

   Firstly between UNIX workstations with TCP/IP networks and later on
   will be with other transport mechanisms also. Closely linked to VCP.
   We have simple MP working and hope to release kroc supporting this in
   the next major release in mid 1997.

Virtual Channel Processor (***)

   The multiprocessing ideas have been evaluated and we are working on a
   software version of a Virtual Channel Processor (VCP) like on the
   T9000 / C104 that will implement the same kind of thing (we don't
   guarantee to be protocol compatible) for multiprocessing KROC. It
   should appear with the multiprocessing in mid 1997.

I/O system improvements (*)

   The current method of accessing I/O blocks when entering the UNIX
   kernel. We hope to replace this with asynchronous/non-blocking I/O
   driven by signals, to give parallel I/O. This will also combine with
   better signal handling and support proper events, in transputer terms.
   This will allow KROC occam to interact better with alien servers (e.g.
   X).

   We re-evaluated this in Early 1996 and decided it was too difficult to
   change since there is no common standard for asynchronous I/O (POSIX
   version isn't implemented on many machines, or isn't done fully).
   However, I/O improvements as part of work for the VCP above may help
   in this area.

Multiple User Interfaces

   We may allow you to pick between the interface you want at the top
   level of your occam program: UNIX stdin, stdout & stderr channels OR
   INMOS SP interface style or others.

Documentation

     * Manual pages
     * User Guide
     * Internals Guide
     * Porters Guide
     * Calling ASM & C functions (*)

Debugging

   A post-mortem debugger. We have thought about this and it is a major
   project that we cannot resource currently.

   We do want to give as much debugging information in the form of file
   names, line numbers and function/PROC names may be possible using
   'stabs' directives in the assembler output.

KERNEL.RUN

   This is a very OS and compiler system dependent but recent changes to
   the kernel code have been made to make this easier to do - more work
   is needed to cope with the dynamic linking of PROCs.

GNU Configuration

   The current source/distribution configuration system is being evolved
   towards the GNU autoconf system and most of it should be in this form
   in the next major release.

Other processor versions

   See TARGETS for more details on other processor targest and the
   groups involved.
     _________________________________________________________________

    Occam For All Team
    ofa-bugs@ukc.ac.uk
    31st March 1997
