KUT

[Tom Novelli]

I just found out about KUT today, and I've been working on something similar
for a few weeks. (How's that for disorganization :-) Actually, I wrote a
bootable Forth interpreter (8086 real mode only) back in August, before I
joined Tunes. Now I'm working on a "Tunes core" prototype, which runs under
Linux or by itself (in protected or real mode).

I downloaded KUT and read doc.txt. I'll tell you the major differences
between my prototype and KUT:
	* I'm only using NASM (except for the Unix interface in C). I'm
building it from the ground up. No other programs are needed to compile.
	* You used C, I used Assembly.
	* I'm writing a V86 handler to support BIOS calls from protected
mode. I have example code to look at, to make this easier.

I'm using a persistent storage system, so all the loader has to do is go
into protected mode (with a few exception handlers) and load one object from
disk: the "Store Manager". I'll write the first few objects in Assembly,
until I can write them within TUNES. For my user interface, I plan to use
Forth for now, since I've already written it... it just needs a few
modifications for handling objects. I can write compilers/interpreters for
better languages (i.e., the new HLL) later..

Anyway, we both need an object format, and also a program to read & write
objects from Linux. Do you have any ideas? I'm still doing research on that.
Like you say, we need specs. I say we, the people who are writing code,
should write our own specs.

Probably the hardest thing will be writing our own assembler, since the
80x86 is so brain-damaged! As an alternative, anytime we need assembly code,
we could assemble it with NASM under Linux, and load it into TUNES as an
object. We could even do that with C routines, by putting a wrapper around
them... hmmm.  Another problem: The 80x86 doesn't support
position-independent code, like the 680x0 does. Bummer. More work for us.

Rough sketch of my object format:
* Name, Address, Size, Type, Flags...
* Sub-objects
* Code --> Every object is also a function <--
* Data can be considered as part of the code.

I'm not sure how well "every object is a function" will work, but I'd like
to try it. Anyway, once I settle on an object format, I can write the
"Persistent Store Manager" object, and I'll have a working prototype!

-- 
Tom Novelli <tcn@clarityconnect.com>
http://www.clarityconnect.com/webpages5/tcn

>     David> Are you still interested in working on KUT?  I think we can
>     David> find you some people to help debug it, if you want.  
> 
> Yes. But I don't have much time to devote to it.
> 
> I just begin to read the OSkit 0.96 reference manual.
> 
> I will probably use it.
> 
> Also, as Faré told me, I will change the name (KUT is a sexual word in
> some european langage -Danish?- and I don't intend anything sexual in
> it). Perhaps TBS (Tunes bootstrapping system).
>
> And I don't even know how to start it. It seems to me that:
> 
> * some primitive user interface is essential. Tunes should not handle
> about static "program" (or meta-program) texts, but about changing
> information. This UI is not graphical - a plain line interface is ok -
> perhaps nearly as primitive as ed or EDLIN - but is needed at the
> beginning.
> 
> * some persistency system
> 
> * some code generating system
> 
> * perhaps some bytecode interpreter
> 
> I need some ideas about specs!