Reinvent the OS cont

[kolla]

And in general about UNIX on 68k, a small list from the top of my head, of projects whos people thought 68k was well suited for un*x usage.
* SunOS
* Domain/OS
* NeXT
* A/UX
* Atari SRV4
* AMIX
* Linux
* NetBSD
* OpenBSD

[kolla]

There is something on the works; Delicate Linux and on May, 29 he started to port it to Amiga.

Nice. I have also used OpenWRT earlier to build small uClibc based boot images for Amiga and Macintosh. For general use though, glibc is more convenient, albeit way more bloated

[Iggy]

No, not quite. Except you understand "self modifying" different from me. A program consists of three types of "memory regions", "code", "data" and "blank space" (bss). In principle, you can write to whatever region you like, but "code" usually contains the program binary, and modifying that by the program is what I would call "self modifying".

Unfortunately, that is only necessary but not sufficient for a program to be pure. It also must not write into the data or bss section, which - apparently - is not granted for your average program. Of course your average program wants to write to its data region, which typically contains C variables with program linkage (aka "global variables"), and of course, you want to write to the bss space (otherwise, it would just stay blank.).

So "pure" programs have to be a lot more careful. You essentially cannot use variables with program linkage (including library bases!), everything must be on the stack, or you must allocate from the heap yourself.

Some compilers come with startup code that create on each program start a copy of the data region on the heap, including manual relocation of the copy of the data space. Needless to say, while this makes programs pure (most of the time at least), it also causes additional overhead.   Why do you need a process for that? And keeping track of each single piece of memory a program allocated is usually too much overhead in first place. The way how Linux works is quite different. Every program gets its own heap, and can do with this memory region what it likes. The program usually includes compiler library routines that implement memory allocation from the heap. This memory allocation is not by the Os. The only exception is when the heap gets too small and requires resizing. Linux (and *ix operating systems in general) usually have a brk() or sbrk() system call to do that. But that's not a "memory allocator". It is usally several layers below malloc(), which is a C standard library function for maintaining the heap.  If the program ends, the entire heap is thrown away. If you start a new process, i.e. by the (infamous) fork(), the heap, stack and code are duplicated, and the separate copy continues execution behind fork(). (Actually, this is usually not a true copy, but rather depends on the "mad cow" trick, i.e. "copy on write").    Which makes it rather hard to implement any C type language on top of it, i.e. the "pureness" you seem to require. Bad idea, if you ask me.    

If I may, I would probably suggest a good book on operating system design.

You have an interesting fixation on your own definition of "pure". And my definition of self modifying code is completely valid, code that directly modifies  the module it runs in.  I never brought in data modules, and have no idea why you would.
As to OS structure, having used operating system before Linux even existed, I'm pretty comfortable with my knowledge level.
Further, nothing I have mentioned limits the use of variables.
One thing you seem to lack is a basic  understanding of kernel calls and operations.

So far, the most intellegent comment I have seen in this thread is the reference to DragonFly BSD.
The hybrid kernel used in that comes close to what I have suggested.
The micro kernel in MorphOS comes closer.

All I have suggested beyond that is reentrancy.
And that is not nearly the burden you seem to think it is.

Maybe you should examine how code used to be written. Then you might have a better understanding of this concept.

Maybe not, after all most Linux and UNIX users tend to gloss over the flaws inherent in their OS' of choice (like the disadvantages in using a monolithic kernel).

[Iggy]

And...to get past this point of contention, drop reentrancy as a goal.
The other points remain valid.
Like DragonFly, a nested kernel with a micro kernal core.
Basic rules that eliminate poor coding techniques that greatly complicate debugging (like self modifying code).

[Iggy]

No, not quite. Except you understand "self modifying" different from me. A program consists of three types of "memory regions", "code", "data" and "blank space" (bss). In principle, you can write to whatever region you like, but "code" usually contains the program binary, and modifying that by the program is what I would call "self modifying".

Unfortunately, that is only necessary but not sufficient for a program to be pure. It also must not write into the data or bss section, which - apparently - is not granted for your average program. Of course your average program wants to write to its data region, which typically contains C variables with program linkage (aka "global variables"), and of course, you want to write to the bss space (otherwise, it would just stay blank.).

So "pure" programs have to be a lot more careful. You essentially cannot use variables with program linkage (including library bases!), everything must be on the stack, or you must allocate from the heap yourself.

Some compilers come with startup code that create on each program start a copy of the data region on the heap, including manual relocation of the copy of the data space. Needless to say, while this makes programs pure (most of the time at least), it also causes additional overhead.   Why do you need a process for that? And keeping track of each single piece of memory a program allocated is usually too much overhead in first place. The way how Linux works is quite different. Every program gets its own heap, and can do with this memory region what it likes. The program usually includes compiler library routines that implement memory allocation from the heap. This memory allocation is not by the Os. The only exception is when the heap gets too small and requires resizing. Linux (and *ix operating systems in general) usually have a brk() or sbrk() system call to do that. But that's not a "memory allocator". It is usally several layers below malloc(), which is a C standard library function for maintaining the heap.  If the program ends, the entire heap is thrown away. If you start a new process, i.e. by the (infamous) fork(), the heap, stack and code are duplicated, and the separate copy continues execution behind fork(). (Actually, this is usually not a true copy, but rather depends on the "mad cow" trick, i.e. "copy on write").    Which makes it rather hard to implement any C type language on top of it, i.e. the "pureness" you seem to require. Bad idea, if you ask me.    

If I may, I would probably suggest a good book on operating system design.

You have an interesting fixation on your own definition of "pure". And my definition of self modifying code is completely valid, code that directly modifies  the module it runs in.  I never brought in data modules, and have no idea why you would.
As to OS structure, having used operating system before Linux even existed, I'm pretty comfortable with my knowledge level.
Further, nothing I have mentioned limits the use of variables.
One thing you seem to lack is a basic  understanding of kernel calls and operations.

So far, the most intellegent comment I have seen in this thread is the reference to DragonFly BSD.
The hybrid kernel used in that comes close to what I have suggested.
The micro kernel in MorphOS comes closer.

All I have suggested beyond that is reentrancy.
And that is not nearly the burden you seem to think it is.

Maybe you should examine how code used to be written. Then you might have a better understanding of this concept.

Maybe not, after all most Linux and UNIX users tend to gloss over the flaws inherent in their OS' of choice (like the disadvantages in using a monolithic kernel).

[kolla]

And...to get past this point of contention, drop reentrancy as a goal.
The other points remain valid.
Like DragonFly, a nested kernel with a micro kernal core.
Basic rules that eliminate poor coding techniques that greatly complicate debugging (like self modifying code).

Oh lordy, please go on fantasizing about the DragonFly "micro kernal", it sounds orgasmic!

[Iggy]

Oh lordy, please go on fantasizing about the DragonFly "micro kernal", it sounds orgasmic!

Actually, micro kernel OS' are no fantasy. QNX, DragonFly, Microware OS9, MorphOS, and almost all process control OS' (as well as plenty of other examples).
And unlike OS' based on a monolithic kernel, many of these can operate in true real time.
Another feature, which Linux has just caught up to, is the ability to dynamically load and unload drivers (much easier when the drivers reside outside the core of the kernel).
And btw, I have plenty of experience with Linux, which is why I am not fond of it.
No great surprise that an Amiga user would be satisfied with Linux as the Amiga never had real time response or stable operation either.
And if we are to continue a legacy of tight, compact software then Linux is definately to be avoided.
I grew up during the period Bell Labs and our nations universities were developing UNIX. Linux is little more than the illegitimate child of UNIX.

Don't you think we can do better than a OS with a 50 year history?
Linux reminds me of Java or Flash in that it isn't that great, but its momentum seems to keep it going.

And you guys can try to attack my credentials, but I was building SWTPC equipment before most of you were born.
Before we really had OS'.
I have worked for a company that built its own 68k based system.
And I had a hand in writing the video drivers for that system and porting a GUI to it.
So...diddle around with your Amigas as much as you like (I'm fond of the platform too), but I have already seen ways where 68k based systems could be improved.

[Iggy]

Now...could we get ON with this discussion.
I am sure the majority of us would be unwilling to trade what we have for yet another Linux derivitive.
So, if we assume a fresh start, with some coding done at levels as low as assembly, all in the name of efficiency - what features would that OS have?

I have already outlined my ideas.
How about a few from all of you that don't suggest a retread of something tired?

[Iggy]

BTW - You all ARE aware that Amiga OS is considered a micro kernel OS, aren't you?

[ElPolloDiabl]

There was a lot of advanced topics you covered. Good job. Could you just pick an OS that has the most software already available?

[Iggy]

There was a lot of advanced topics you covered. Good job. Could you just pick an OS that has the most software already available?

Well heck, then we'd have to go with Windows, OSX, or Linux, and I don't want to do that.
Even Amiga OS has a better software base than what I'm suggesting.
This is where Thorham and I agree, the lack of software would be a major disadvantage.

[ElPolloDiabl]

I like the OS 9 microkernel approach. Should you have software to run on it as its ready? E.g. goal:
Networking
File manager
are some suggestions.

[trekiej]

If there was a community built 68K computer, what bus do you think would be good to use?
vme, zorro, s100, etc.

[guest11527]

You have an interesting fixation on your own definition of "pure".

This is not my definition of "pure". It is the AmigaDos definition of "pure". Sounds strange? Maybe. But I did not design this stuff.

[Iggy]

This is not my definition of "pure". It is the AmigaDos definition of "pure". Sounds strange? Maybe. But I did not design this stuff.

My apologies. I am not here for contention.
Obviously much of what I am considering would definitely be "impure".
And after thinking about your posts, reentrancy isn't really a necessity with as much memory as we can use.
With a 1.5 GB memory range, and an efficient processor, the added complications may not be worth it.

[kolla]

Iggy, I have issues with you calling the DragonFly kernel a micro kernel, it is not a micro kernel design, it is a hybrid at best, with some features most known from micro kernel environments. If DragonFly is a micro kernel, then FreeBSD is too, or any *ix that pushes features out in userland. Do you consider Darwin a micro kernel OS? It used to be.

I find it funny how DragonFly keeps coming up as a buzz word among amiga users, but how many of those mentioning it has actually used it?! For the record, I have, at work even, evaluating HAMMER for possible use in production environments. Eagerly awaiting HAMMER2 to evaluate for a possible multimaster cluster FS solution.