arf2 Re:ORG,KER+ far12

[Andreas Arff]

Hello Again, continuing my last message

> >> I feel however that this addressing should be centralised rather then be
> >> scattered among the various device drivers
> >> (1) It means less repeated work in the device drivers
> >> (2) It's simpler to keep track of and maintain.

I agree on both your points, and I could add another one,
(3) It gives a more "generic" interface when you want to add a function to it.

But I don't think it should be done this way anyway, beacuse it will be
a very sensitive colossus. A small error and all devices could go to hell.
I think it is easier for each device driver developer to maintain it's own
list/tree. You won't get any overhead when the device raises an event.
The devices will live their own life in a way.
If we have a centralized address server we'll have to do more code to get it
work. The list/tree would be larger thus increasing the time used to traverse
it.
Of course we should have a library for the device driver developer so he won't
have to build everything on his own.


> >> > MOOSE should be Pee O aRe Tee A Bee eL Ee. However, we all come to have 386
> >>
> >> I hate to say this but the AMiga isn't better -- the A600 and A1200 are based
>
> >> The good thing about Amigas is the operating system
>
> YES, and the copros (and the fact the OS runs perfectly with the copros)

I deleted most of your text here, becuse it is irrelevant. That is not what
Fare ment. It should be portable, but of course there must be some sort of
limit regarding what features the prosessor have, have not.
It wasn't important whether it was an Amiga or anything else. Looking forward
to launch moose on a NeXT:-).


> >> > >> > (13) Should we be providing threads? (I don't think so but am open to debate)
> >> > what are threads/tasks but little/large objects ? Why build such a distinction
>
> >> Threads share data space whereas tasks/processes don't.
> >> Tasks are objects.
> >> Threads would correspond to concurrent method activation within an object.
> >> Since the data is shared between the threads locking becomes important.
>
> Again, that seems a totally arbitrary distinction: you always share
> something with someone (or else, the process has NO interest); UI programs
> would like to share windowing memory with the main UI device; piped programs
> can happily run with a shared memory pipe, etc; there's no limit to sharing
> little or big objects. On the opposite, you'll never want to share
> everything (at least, you won't have the same stack and/or registers). So
> threads and tasks are no absolute concepts, but relative ones: if you share
> memory with another one, you're a thread to it, if not you're a task ! That
> becomes ridiculous. If unix created two words, it's because of a unix badly
> fixed misconception, not because of an improvement.

Then let us define the MOOSE thread. Someone feeling it is his mission in this
life? I'll start a thread about them, see my next message.



> >> > * about DOS FAT systems:
> >> > Some talk about reading/writing it. Of course, this is obvious on 386 based
> >> > computers. But DOS FAT is so @#$^#$%^& that no sensible people would willingly
> >> > use an OS with it as a main FS. Whatever FS is choosen to work on, this should
> >> > be included as a device driver, not in the Kernel.
> >> For the moment DOS compatibility is a definite plus.
> Yes, and in the future, OS/2, linux, * compatibility also; and an emulator
> would be even greater; but this has nothing to do with the Kernel, and DOS
> FAT shouldn't be our primary FS (which does not mean we cannot have a generic
> FS running inside DOS FAT system, as any other FS)

File systems.
Ok, a device can make any type of partitoning (?) he want, dos/mac/unix.
The reasons we make it dos compatible is because we run dos. What if we had
to redo the whole filesystem, the way we want to have it, before we start
coding on moose, for the reason we don't like it.
The point is not to be dos compatible, the point is _we_don't_have_to_build_
_something_new_before_we_start_the_real_work.
When moose is working more or less ok, we can/should change the file system.

> >> > * Could one explain a poor ignorant frenchman the joke about Moose ?
> >> > ('heard you talk about a Mr Moose; who was it ? )
> >> Some american cartoon ... :-)
>
> Is there nothing more about it ?
I see we europeans must stick together:-)


> >> >  In fact, I think the Kernel Set should be exactly the C/ASM coded methods for
> >> > handling low-level objects: tasks/thread/procedures (executable code in
> >> > general, including stack management, and exception handling), memory
> >> > allocation, object typing, virtual pointers and naming (including subnaming
> >> > and polymorphism, linking and unlinking object to the running system (imagine
> >> > the coding/decoding needed to load/save an object from the running session
> >> > from/to mass memory). Nothing more.
>
> >> Nothing MORE?!
> >> I do not think that object typing, polymorphism etc. belong in the kernel.
> >> Object typing should be done at compile time.
> >> If you want an interprative system that can be written but you shouldn't
> >> FORCE the system to do interpratation.

The most important thing is to keep the kernel as clean as possible.
Summing up what I think we agree in.
Kernel should contain:
1) MultiTasking, LL memory routines (both virtual and physical).
   Some kind of messaging for kernel events that affects the running tasks.
I'll come back to this in my next mail.

> If we are one day able to have a standard interchange format for data&code, it
> is compulsory to include it in base system (I'm not talking about the Kernel
> only, but also the set of standard devices available). If we are to quickly
> interchange code, we cannot afford compiling a HLL program each time; so a LLL
> is good; if the LLL CAN be interpreted (but is also aimed at compiling), it
> is all the better, as it saves great amount of time for HL routines.
> (that's infinitely more efficient than, say, a shell&awk script). I'm not
> trying to impose an interpretative only system. I'd hate that. But I'm
> also pretending that writing the interpreter before the compiler is easier,
> and we don't need lightning speed to first boot the system. When the system
> is stable, we can begin compiling everything.
Sounds like a good strategy.

> >> To summarise my comments:
> >> The main problem is that you are confusing language and OS issues.
>
> I don't think I'm CONFUSING them, but I sure am linking them.
> I'd like the others to bring their viewpoint upon this critical point.
> Support me, question me, criticize me, flame me; but please reply as
> Michael did.

We mustn't write a system that is only that, uninterfacable to anything else
but itself and we mustn't write a system where only one language is supported.
I think if we can have a low level of abstraction in device code, no one is
going to interface it through low level routines anyway - if not writeing
his whole own HL interface library :-).
I think that if we create many functions that does little, the compiler
vendor is more free to do what ever he wants with them and that is good,
but on the other way, it can be used in ways we didn't expected and hence
bad.
So, for some code - write very low level functions that the vendor has to
assemble to do something at all, and for other - provide a higher level of
abstraction.
One example. Memory management. Have three functions, AllocMem, FreeMem and
ReAllocMem that allocates "large" chunks (from 1kB to 4GB/0xffff large for
intel).
For keyboards, have a higher level of functions as GetKey, not the type of
function GetPointerToKeyboardBuffer.
Now if I totaly missed what you ment...sorry:-).

> >> * You should allow the use of non OO languages -- otherwise you don't have a
> >> generic OS -- you have an OO programming environment.
>
> I have the same answer, and I have spoken about that just before.
mOOse! Not saying we must OO everything, maybe we should call it mose?
There is something in the name that says OO SystEm.

> >> Note that objects come ABOVE the kernel.
>
> Above the KERNEL, I don't know. But IMO certainly not above the basic system
> (kernel+device) set.
Agreed, but if someone want to make an OO'ed device for their MucetyMuc
device.

> >> You don't want to have the kernel enforce complex semantical policies.
> >> By lifting up such things into the compiiers you gain in efficiency and more
> >> importantly in maintainability.
>
> By having (simple) semantical policies enforced you can at last have a
> transparent system where apps truely can communicate with each other
> (and not only merge results as most "advanced" current systems only do).
>
> >> Requiring the kernel to do polymorphic type checking and inheritance is like
> >> requiring an OS to run structured code ...
>
> Uh ?

We just write a data exchange device ABOVE the kernel that does all this,
I can't imagine even in my wildest dreams that the kernel is interested in
what the task would want to do, as long as it don't requires the kernel to do
it :-).

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--