On Tuesday 20 February 2007 14:00, GDKBadmin wrote:
> Hello Jan,

Hi Cheshire,

> Little note on those Minix3... it works... sometimes))... I run it...
> C and microkernel leads to long debug?

No real experience yet. I just did some test with 'Hello world' program.

> But... Microkernels just provide some protection for leaky legacy C
> programs. What if use language-based solution for problem?
> Good languages, like Modula-2 or Oberon, seems provide same level of
> protection as microkernels. And without so much _mandatory_ overhead.

I agree. But at the moment, there just is no Modula-2 based operating
system. After Lilith and Oberon it was just Unix and Windows. Both made
with millions of lines of C sources.

> So we don't need Minix3, we just need good free Modula2/Oberon
> compiler as system language.

You are right.

> On top of standart monolithic kernel.

I see the monolithic kernel as a result of the too many PC products.
There are millions of ways to assemble one personal computer. It would
be very good if one set of components was chosen as a standard PC and
development would be based on that one set of hardware components.

Something like the OPC laptop. Or a desktop with:

- standard mainboard with i386 processor or better
- VESA standard VGA card
- PS/2 mouse and keyboard
- IDE disk and CD-Writer
- RTL8139 based NIC
- 4 USB type 2.0 ports

In fact, something like my Lithium computer.

> And native system library for compiler, based on direct syscalls. to
> replace leaky libc.

Yes, that would be ideal. But it would be necessary to write a new small
kernel in assembler for the standardised hardware. A terrible job.

> At first support for NetBSD/Linux on i386 will be sufficient.

What do you mean with this?

> In compilers first consider reliability and simplicity. Sophisticated
> optimisations not required at all. (simple tests shows that modula-2
> compilers produce slightly faster programs than gcc -O2. just because
> of strong typing. so performance is sufficient.)

OK, that makes things easier.

> Something like Oberon-0 compiler? Modula-0?))

This is high on my list of priorities for many years now. I managed to
port the first part of the Oberon-0 compiler to Linux. I just need to
port the rest....

> m2f problematic, gm2 too linked to gcc/libc by definition, xds is
> proprietary...

Correct.

> if forget about codegen changes and proprietarity of BEG, only mocka
> remains?

It comes close. But I am pretty sure that also Mocka is based on many
'FOREIGN' modules which use the libc functions in a wrapper. So a 'new
one' would be best.

> Then we can rewrite NetBSD kern... or those Minix3 if wish... but in
> Modula2, not in C-trash...

Wouldn't it be better to rewrite those parts in assembler? Minix 3 is
nice, but it has the same basis as Linux.
In my ideal setting, Oberon-0 would be the right choice. A small
language to do the dirty tricks. Later build a bigger language
(Modula-2) with the Oberon-0 compiler.

> Then applications... Good web-server, extensible by modula-compiled
> snippets, based on thttpd. (to replace PHP/LAMP trash)... Postgress
> DB... and so on... ))

I am not sure if I could build such a compiler...

> at this time i know only one Unix-like os in modula2 - Lumos...
> and it's old, for m68...

If you have the source in Modula-2, that should not be the biggest
problem.
I found it in a ZIP file. I could not open the arj file in Linux. It
looks promising. It even has a TCP/IP stack inside.

I will upload this file to the mocak files area.

Familiar with this: http://www-spin.cs.washington.edu/ ?

Found it on http://freepages.modula2.org/m2faq.html (thanks Christian!).

> Now i already experimenting with mocka on linux and netbsd. but mocka
> library linked to libc, like in XDS modula.

Correct. The core of Mocka is based on C libraries. It could be an
option to rewrite the lowest level parts in GAS and then chain them
together with DEF/IMP modules. A lot of work but not as much as writing
a new compiler for Lumos I think.

> So i thinking on own static syscall library. Just planning. Making
> table of common syscalls, making list of ISO modules for modula2 etc.

If you keep us informed, perhaps some of us can help you.

> ACK toolkit use stack-based internal representation like GardensPoint
> Modula etc... I'd like to hear comments on _quality_ of ACK compiler.
> Minix3 not so iteresting, only ACK...))

On http://fruttenboel.verhoeven272.nl/minix/download.html you can
download the documentation for the ACK m2 compiler.

--
Met vriendelijke groeten,

Jan Verhoeven
http://fruttenboel.verhoeven272.nl