TUNES Activity

[Francois-Rene Rideau]

> I got into this via Mike's project (classified here as "LLL").  The
> goals currently expressed are significantly different from those that
> originally got me interested.
   Well, there is no permanent maintainer currently for the LLL and
Migration subprojects, which are the parts Mike gathered us about,
and as I don't have time to maintain everything, I don't insist enough
on this subproject as it's not the favorite in my mind.
Perhaps *you* could become the maintainer of one of these projects ?


> Basically, I don't see that there are any current goals here which
> require discarding the underlying operating system.  The present
> effort seems to concentrate on user interface issues.
   Mike said we should be able to implement over POSIX, and I agree.
Discarding the underlying OS is for speed, response, and reliability,
at greater expense and smaller portability. We should also do it if we
have time, and even perhaps design the hardware (I'd love a modular
muP21/muP32 based multi-CPU architecture) but I'd leave that to the FIRE
project.
   The problem is both HLL and LLL must be deeply codesigned.
If nobody expresses any opinion about the HLL, how could anyone have a
motivated opinion about the LLL ?
   Features like lazy evaluation, garbage collection, migrability,
reversible partial evaluation have a deep impact on the LLL design.
   I proposed that there be a modular LLL approach, that word-compressed
LLL programs would import words from modules and combine them, and these
words would be partially evaluated (compiled, inlined, optimized, whatever)
when loaded and scheduled. Different set of LLL words could have completely
different behavior. As a standard, we would provide
a) a cooperatively multithreaded heap-based machine, with a local stack
that would be lost during PAUSEs (persistent stack would use frames in a
the GCable heap)
b) and a preemptively multitasking stack-based machine with fixed-size
stacks and manual GC, for real-time routines (restricted access to
trusted users only, for low-level device drivers, e.g. interrupt handlers,
fast video routines, etc).


> Oh, sure, there's concepts like "we don't need ___" (fill in the
> blank).  But it seems, to me, most useful to consider those statements
> as "we don't need to address ___".
Err, I'm not sure what you mean here (i.e. how you fill in those blanks...).


> Basically, it looks to me like you're at a prototype stage, and (a) it
> doesn't seem like the prototype ought to be very hard, and
> (b) I'd be more worried about not understanding your intent than I would
> be about any technical issue relating to implementation.


> Does this make sense?
   Yes it does. But does that also mean that I should work out the
prototype all alone ? ): ): ):

> -- 
> Raul Miller
> 

--    ,        	                                ,           _ 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 URL: http://acacia.ens.fr:8080/home/rideau/Tunes/