KUT, etc

[Francois-Rene Rideau]

On Fri, Jan 15, 1999 at 08:17:41PM +0100, Basile STARYNKEVITCH wrote:
> I am not sure that this means that all these parrallel (or
> competitive) efforts about a low level approach to Tunes should be
> stopped or merged.
Well, I think that the principle behind the oskit is correct:
certainly, people who want to hit the bare metal must be able to grow
their own experience, but everyone is only interested in a few aspects,
and a modular approach allows people to each focus on what one is
interested in, while not being forced to learn too much of the rest.
Emmanuel Marty <core@suntech.fr> is also building his kernel-less system
on a modular approach, and very open to adapting his module system to our
requirements. All in all, I think any Tunes-related low-level effort should
be based either on the oskit or

>>> Anyway, we both need an object format, and also a program to
>>> read & write objects from Linux.
Oh, btw, core has been developing the XCOM binary object format,
so as to exchange portable components that can include code for several
different "architectures", with proper metadata for them to be managed
without the need for external/implicit assumptions. I'm sure the format
isn't perfect, but it is fully open to our adaptations, and the author (core)
is willing to help.

> I'm not sure that a persistency system could live in Linux as easily as
> it could live on the hardware (or in a specially designed tiny kernel)
I can imagine how a linux process could live "as if" it was in a fixed
pool of "physical memory", without virtual memory (though with properly
displaced memory "segment", if the high bits are to be used as
pointer/integer tags), and using read/write/fdatasync as an I/O driver.

> Agreed. Oskit 0.97 just came out!
Good!

>     Fare> BTW, a very important feature will be the ability to unlink
>     Fare> then relink an object, for purposes of migration, gc,
>     Fare> persistence, etc.  This requires access to information
>     Fare> usually not revealed by the linker/assembler.
>
> agreed.
>
Once we do have the basic unlink/relink mechanism,
we have enough to build the rest of the reflective system.
It is still time later to add performance optimizations
depending on whether we run on top of Linux or on bare hardware
(and which bare hardware -- a plain 68k PalmPilot won't be the same
as a 1GHz Alpha).

>     >> Rough sketch of my object format:
>     Fare> I recommend you get direct inspiration from CMUCL or RScheme
>     Fare> or OCAML, rather than invent something new.
> 
> Agreed. I will look again into OCAML stuff.

BTW, happy new year!

[ "Faré" | VN: Уng-Vû Bân | Join the TUNES project!   http://www.tunes.org/  ]
[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics  | Project for  a Free Reflective  Computing System ]
The [classical] liberal, of course, does not deny that there are
some superior people - he is not an egalitarian - but he denies
that anyone has authority to decide who these superior people are.
		-- F. A. Hayek, "Why I Am Not a Conservative"