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.
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 ?
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.