About a new HLL

[Francois-Rene Rideau]

> Just tossing in some spare change.
> (and testing that my reply/post is working :-)

   Ahem. fare@ens.fr is a buggy address (fare is my usual login at home,
but the login I receive e-mail to at school is rideau). But I got the
message by tunes@ens.fr which works.


> I have (since before java came on the scene) believed that the future
> of program execution lies in "byte code" compiled programs executing
> on a portable interpreter.
> It would be nice to be able to port an OS
> to a new platform and have the (compiled) programs from all the other
> existing platforms execute without modification.

   The P-Code based OS from UCSD in the late 70's already used portable
bytecodes. Today, lots of language systems like emacs lisp, caml,
clisp, etc, have portable bytecode systems.
   TAOS, a commercial OS, uses a RISCish "portable assembler" language
that each architecture assembles to its own code before it gets executed.
Mac/68K emulators that run on PCs or PowerPCs have no problem with
dynamically recompiling 68K assembly into native assembly with good
performance (roughly one 68K instruction to three native code instructions)
and response time.
   Even traditional unices manage to share a same environment by mounting
architecture-dependent partitions on similar trees and using architecture
dependent paths to find the right binaries.
   So techniques for cross-architecture computing have always existed,
and many other techniques haven't been explored yet. What prevented them
from being widespread is the strength of hardware-based industrial standard
rather than software-based ones.
   The "traditional argument" against executable code portability that
rejects it because of its overhead is ridiculous when you see how much
greater is the overhead induced by the traditional low-level coarse-grained
centralized computing model, and the stubborn techniques used by them (see
above about unix).

   Now, portability is one thing, distribution is another:
in the first case, you want a program to be able to run and complete on
any of many architectures; if you have a scheduler that dispatches
processes at launch-time, you have coarse process-grained distribution.
   But we at Tunes want persistency and dynamism; programs sit there
with their data and are dynamically modified; the load for a program
may change a lot, and process-grained distribution is too coarse, has
no meaning; we thus require code to be able to migrate from one platform
to another, which is quite a harder thing, and consistently, we require
fine-grained computing, and high-level, not low-level portability
standards; this also should allow code to distribute both meaningfully
and efficiently over completely different platforms (16/20/32/64 bit,
with lots or few registers or a stack without any register,
with a RISC or CISC instruction set).
   This means that our portable objects must be much nearer to parsed source
code than to compiled binary code, and will be compiled or interpreted at
run-time. Efficiency, which lies in critical code sections, is easily
achieved by packaging optimizing hints with code, so that the compiler
won't waste time on what makes it slow, optimization; in the most extreme
case, such optimizing hints will be a choice of architecture-dependent
optimized versions of the code.
   As for the overhead of scheduling fine-grained code, it is not a big
problem. In a degenerate case, you just don't schedule, and obtain exactly
the same behavior as exists in non-distributed OSes. In a smarter case,
if you can do resource-based scheduling: availability of resource (e.g. an
idle computer) only, or use of resources large enough, will trigger
scheduling, so that no overhead will be felt if no resource are available,
while if resource are available, the overhead will be more than largely
compensated by the time gained by activating or managing resources that
would have been seriously under-used on a non-distributed environment.

   About TAOS, Plan9, Amoeba, and other distributed OSes, see our OS page:
"http://www.eleves.ens.fr:8080/home/rideau/Tunes/Review/OSes.html"
   About caml and other language systems, see the Tunes Languages page:
"http://www.eleves.ens.fr:8080/home/rideau/Tunes/Review/Languages.html"
   About fine grained distribution, see our Migration subproject:
"http://www.eleves.ens.fr:8080/home/rideau/Tunes/Migration/Migration.html"

   Feedback welcome.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"