The Tunes OTOP Subproject


Contents of the OTOP Subproject

Here are the current contents of this OTOP project:
  • Firstly, the goals of the subproject
  • Then, a first sketch of various implementation ideas that fit the OTOP project
  • A list of difficulties about the OTOP
  • What's been done already

    You may also want to go back to the Tunes LLL subproject, or to the main Tunes page, or to the Tunes Subproject page.


    Goals for the OTOP subproject

    The OTOP subproject aims at implementing the Tunes project On Top Of POSIX, so that Tunes runs on any new hardware, as POSIX is (sadly, but it could be sadlier even) the one standard, which is ported on any new architecture (actually, most new architectures are conceived will POSIX in mind).
    Thus, as new hardware platforms grow in power, even if OTOP offers only a constant 10% of efficiency as compared to "optimized C", it will allow TUNES to follow hardware enhancements, and may be a platform to develop architecture-specific implementations. Moreover, architecture-specific enhancements to the POSIX implementation, even if slower and less reliable than a full port, may provide more speed and much more functionality than standard POSIX optimized C...
    The implementation should be faithful to the LLL specifications, and device drivers should be provided to allow basic memory management, human interaction, and access to mass storage.


    Implementation ideas

  • Some say C is a portable assembly language. Why not take them at their word, and produce some assembly-like C source, with global variables, labels, jumps in a one big procedure, using m4 as a macro-processor, and/or outputing C from the HLL ? This way, we will be really building a generic assembly implementation of the Tunes LLL, not having to build a completely different C based one, while still taking advantage of C optimizing compilers, and we can use our specific calling and multithreading conventions without interfering with the C calling stack (still useful for I/O).
  • Shall we use the C calling stack as a the GC'ed heap, as does Henry G Baker ?


    OTOP Difficulties

  • See LLL difficulties...
  • Having some hardware independence, but limit inefficient code to the least possible.

  • Points where POSIX particularly sucks
    • There is no reliable way to be sure that disk buffers are flushed. The only thing to do is to pray and insist on the user do regular (incremental and full) backups
    • Modifying the memory mapping tables to do garbage collection is very slow, as it involves a syscall for each operation, and leads to big memory mapping tables for which POSIX implementations is not optimized at all.
    • There is no standard or reliable way to reserve a large chunk of address space without cluttering up swap memory and without creating a mess with the C library, particularly if we want to reuse addresses from a swap file accross sessions. On each architecture, we will have to add some architecture-dependent memory mapping instructions
    • When resuming connections, there is absolutely NO WAY to trust the files to be in the right format; we must check, recheck, and re-recheck permanently. The persistent files must be in read-only mode, and be changed to read/write mode just when open by the right process (use the permission mode as an open indicator ?)
    • To allow multithreading, special care will have to be taken to do only non-blocking I/O with select() and such, to queue requests, etc. Yuck.
    • There no way to have safe real-time response. So bad for games, animations, etc.

  • Garbage Collecting
    • Paging under POSIX is too slow and messy. Should be done as seldom as possible (only at minor and major GC)
    • We'll sacrify the low bit of words, but use macros to choose whether integers or pointers will be unchanged.


    To Do on this page

  • A lot of work...


    Back to the TunesLLL subproject.


    Page Maintainer:
    Faré -- rideau@clipper.ens.fr