KUT

[David Manifold]

> Work is going on very slowly, but it is taking a lot of my (spare) 
> time. And I am not a PC hardware (or Intel x86 lowlevel) expert so it is
> quite difficult for me. 
[...]
> The most urgent hardware question is how to get extended VGA, ie 80x44
> screen resolution. (like Linux does)? Any clues.

You can easily see how to set video mode in arch/i386/boot/video.S, of the
linux kernel source.  I'd think if I was programming a self-contained
pmode kernel, I'd read the linux code very closely for other things
besides video mode, too.

> I also need a lot of encouragement. Will my small effort be useful to
> TUNES? I hope so, ...

I don't see how it can hurt.  It could allow someone to begin working on
dynamic compilation, along with Fare's cooperative multithreading.  Here's
how I see TUNES working at the CPU level in the long term:  The "kernel"
is just the thread that controls what code the CPU runs.  It's main job is
to feed the code to the CPU.  Fare was talking about cooperating threads
having instructions written in between their instructions at regular
intervals to check whether any other tasks needed running.  I would like
to extend this idea, and have the TUNES kernel dynamically optimize
multiple simultaneous running threads, using the knowledge from the source
code of both.  Instead of compiling each program to a single binary, which
execute independently, TUNES needs to recompile programs on the fly to be
aware of each other.  For example, if I am playing Tetris and downloading,
there may be tetris instructions and download instructions intermixed in
the same memory space.  It could be more efficient this way, since there
would be no procedure call overhead, no task swap, etc.  The task
threading mechanism would thread itself into every task in the same way so
that it kept being called.  I imagine the CPU never having to do long
jumps until it reaches the end of memory, with the threader constantly
writing new code just ahead of the instruction pointer.  (If memory
address wraps at the end, even better)  I'm not saying this is a realistic
or efficient way to implement anything.  I am saying we need to consider
completely new ways of looking at the low-level functioning of an OS.  One
thing I noticed about most OSes is there is a lot of jumping around.  If
this slows it down, there should be a way to avoid jumping around.  But
this is just one example of things to look at.  

Eventually someone will have to do work in this area for TUNES.  A scheme
compiler seems kind of close to this, so maybe someone wants to work on it
now?  I'm working only on high level stuff.  When I am just about done
with the high level stuff, I will need some really smart low-level
translators such as I describe above.  I guess if someone works on it now
it can be ready by the time it is needed, instead of at some point having
some really slow high-level code.  

In any case, write well-commented, clear code.  That way it'll be useful
for anyone, in the TUNES project or not.

There are probably other things besides dynamic compilation that KUT will
help, too.  Has anyone applied the results of Kris De Volder's
dissertation (that Fare posted recently) to our project yet?  How well
does Scheme allow "Turing-complete meta-programming"? 

David Manifold <dem@tunes.org>

And oh! It was as though the heavens opened and God handed down a
client-side OS so beautiful, so graceful, and so elegant that a million
Microsoft developers couldn't have invented it even if they had a hundred
years and a thousand crates of Jolt cola. --Polly Sprenger, LanTimes