new energies for the LLL

[Francois-Rene Rideau]

>>    The rule I proposed for Tunes, [...]
>> is that anyone can use any language seems to suit best,
>> but *must* agree to translate all his work
>> into any language that the project may choose later. [...]
>> then I'm ready to translate all my existing code.
>
> I'm ready to do the translation but I might have problems with some
> complex m4 macros.
   Please note that you'd better start from the actual code files
and translate macros as you see how they are used,
rather than translate macros from the macro files
and desperately trying to understand what they try to do.
   Mail me about whatever m4 macro seems ununderstandable
as for what it is meant to do, so I translate it or explain it.


> I'm ready to help after that also but I will require some guidance
> at first. The question is, do you need my help. I do not have a
> picture of what we are doing that is as clear as yours and that
> means I couln't take the initiative in figuring out what to do next.
   We'll have to maintain a dynamical TODO list
and assign parts of to various maintainers.
   See next message.


> Is there something that you can tell me to do that takes less time to
> explain that to do it yourself ? (taking into account that communication
> is difficult given the distance and the number of time-zones between us)
> One thing I can do now is look for suitable implementations of Scheme.
   I can't do Tunes on Friday, Monday, and Sunday,
and only part time the other days.
So the France-Canada overhead is not as important as it seems.


> The will to learn by reading I guess.
> I've got Robert Hummel's book on the x86.
   It has many mistakes and holes (in my edition),
but seemingly all such books have,
because the x86 cpus are such a mess !

> I don't have anything on building a 32 bit OS for the x86 although
> I've seen one in a bookstore. Do I need that ?
   Definitely NOT.
All books I've read about OS design were twenty years out of date as
for design.
   You can read through the book in the bookstore,
but I don't recommend anything I know
[Please make me wrong and show me a good book].
   The best information is on-line:
* the LKHG (from the Linux Documentation Project)
 for a description of traditional OS implementation.
* all the *source* code I talk about in the 0.0.0.25 src/LLL/i386/README
 and doc/info/i386* for actual code examples.


> Also I guess I should find that famous list of interrupts.
> If you know what I'm talking about could you give me a pointer to it ?
  grep for x2ftp.oulu.fi the Tunes docs and READMEs.


> It's not the assembler/machine that worries me,
> it is the stuff about setting up the segments/pages,
   Apart from a few low-level primitives,
this should be all high-level programming.
   Let's keep everything modular,
and offer trivial (though inefficient) implementations at first.
   For instance, we'd first have
a unique throw-it-all heap of tagged objects,
with a stop-and-copy GC,
with trivial unportable memory-to-disk persistency mapping,
with simple I/O subroutines, perhaps through BIOS.


> interacting with the BIOS to control the keyboard and screen.
   This one is trickier.
Either we do support BIOS or do direct I/O,
we should steal code from other programs, preferrably PD.


>>    Why not take up the OTOP subproject (the same thing in C) ?
> Unfortunately, I don't really understand what is POSIX (got references?)
> and therefore OTOP.
   POSIX is the OS standard from the ISO,
toward which all OSes currently converge,
and that Unices (among which Linux) already embody
(though Linux doesn't have standard extensions like real-time).
   The official POSIX documents are not worth the money you'd spend for them
if what you want is doing TUNES. The man pages for standard C functions
and info pages for the GNU libc are a good start to know what POSIX means:
the embodyment of traditional computing that Tunes want to transcend.


> Also it would
> be nice if my efforts could accelerate the developement
> of the first implementation rather than create a second one.
> (But we should keep OTOP in mind while we work on i386 to allow
> for easy retargetability).
    I already started writing m4 macros for the OTOP.
Now I see how wrong I was. Let's first focus on getting Scheme to work.

--    ,        	                                ,           _ 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/"