Reimplenting Linux Kernel in Python

[Maboroshi]

Hello

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in python
basically just taking the source code from linux and rewriting it in
python Would this idea make sense to do - if so what would be the
benefits of doing this and in what way would this not be a good idea

Cheers

[Peter L Hansen]

Maboroshi wrote:

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in python
basically just taking the source code from linux and rewriting it in
python Would this idea make sense to do - if so what would be the
benefits of doing this and in what way would this not be a good idea

Um, you're the one suggesting a re-write. Doesn't that mean
it's sort of your job to know the benefits of doing it? There
are certainly endless reasons why it's not a good idea...

-Peter

[Maboroshi]

Peter L Hansen wrote:

Maboroshi wrote:

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in
python basically just taking the source code from linux and rewriting
it in python Would this idea make sense to do - if so what would be
the benefits of doing this and in what way would this not be a good idea

Um, you're the one suggesting a re-write. Doesn't that mean
it's sort of your job to know the benefits of doing it? There
are certainly endless reasons why it's not a good idea...

-Peter

Um sorry I should say in your opinion what would be the benefits and
also what would be the disbenefits
Um, you're the one suggesting a re-write. Doesn't that mean
it's sort of your job to know the benefits of doing it?

I understand some of the benefits but not all

Cheers

[Peter L Hansen]

Maboroshi wrote:

Peter L Hansen wrote:

Maboroshi wrote:

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in
python basically just taking the source code from linux and rewriting
it in python Would this idea make sense to do - if so what would be
the benefits of doing this and in what way would this not be a good idea

Um, you're the one suggesting a re-write. Doesn't that mean
it's sort of your job to know the benefits of doing it? There
are certainly endless reasons why it's not a good idea...

Um sorry I should say in your opinion what would be the benefits and
also what would be the disbenefits

> Um, you're the one suggesting a re-write. Doesn't that mean
> it's sort of your job to know the benefits of doing it?

I understand some of the benefits but not all

Let me be more explicit then. I think this is an idea that
is based on very little understanding of what is involved,
to the point that I think it would be pointless to discuss
it without knowing what are the things *you* perceive as
being benefits, and what disadvantages or potential road-blocks
*you* have already thought of.

-Peter

[Phil Frost]

You should take a look at Cleese <http://www.jtauber.com/cleese> and
Unununium <http://unununium.org/>

On Wed, Oct 13, 2004 at 03:32:01PM -0700, Maboroshi wrote:

Hello

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in python
basically just taking the source code from linux and rewriting it in
python Would this idea make sense to do - if so what would be the
benefits of doing this and in what way would this not be a good idea

Cheers

[Carlos Ribeiro]

On Wed, 13 Oct 2004 15:32:01 -0700, Maboroshi <no****@hotmail.com> wrote:

Hello

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in python
basically just taking the source code from linux and rewriting it in
python Would this idea make sense to do - if so what would be the
benefits of doing this and in what way would this not be a good idea

To put it simply, it does not make sense, in its pure form. Linux is
written in C for a lot of good reasons: portability, need to access
the hardware, and performance comes to mind. Besides that, Linux is
Posix compliant and emulates Unix system calls to a large extend, and
that also makes C a natural choice. To do a similar implementation in
Python would be similar to try to use a knife to sculpt a marble piece
-- it's the wrong tool for the job.

Now, let me re-state your question in a broader sense. Is it possible
to write an OS using a language such as Python? Yes. But the resulting
OS will surely be different from Linux -- by design it would be a
completely different beast. Some parts would still be written in C and
assembler, because it needs to access the hardware, and also for
performance reasons. But an API could be devised to allow higher-level
functions to be written in Python, while calling the low-level
C+assembler stuff. But as I said, it's _so_ completely different from
anything else in use today as to make it pretty much a theorethical or
academic exercise with little practical use. I can't see a project
like that taking off, even if I would love to see it working.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com

[Grant Edwards]

On 2004-10-13, Carlos Ribeiro <ca********@gmail.com> wrote:

To put it simply, it does not make sense, in its pure form.
Linux is written in C for a lot of good reasons: portability,
need to access the hardware, and performance comes to mind.
Definitely.
Besides that, Linux is Posix compliant and emulates Unix
system calls to a large extend, and that also makes C a
natural choice.

Not sure I follow on that point. Any low level language that
can deal with a C "struct" and byte-addressible memory would be
fine.

--
Grant Edwards grante Yow! I'll show you MY
at telex number if you show
visi.com me YOURS...

[Phil Frost]

On Wed, Oct 13, 2004 at 08:24:48PM -0300, Carlos Ribeiro wrote:

...

Now, let me re-state your question in a broader sense. Is it possible
to write an OS using a language such as Python? Yes. But the resulting
OS will surely be different from Linux -- by design it would be a
completely different beast. Some parts would still be written in C and
assembler, because it needs to access the hardware, and also for
performance reasons. But an API could be devised to allow higher-level
functions to be written in Python, while calling the low-level
C+assembler stuff. But as I said, it's _so_ completely different from
anything else in use today as to make it pretty much a theorethical or
academic exercise with little practical use. I can't see a project
like that taking off, even if I would love to see it working.

I can state from first-hand experience that this idea is not too
far-fetched. It is possible to enable Python to express device drivers
and low level OS functions like multitasking with an amazingly small
amount of C+asm; I'd say around 2000 lines, excluding the Python
runtime. If Pyrex counts as not-C, then I bet it could be done in 500.

The performance problems are a bit harder, but with a good JIT compiling
VM the runtime performance of Python could theoretically come very close
to C.

I do agree though that there is little point in rewriting Linux in
Python. The advantage in Python is its expressiveness, but by rewriting
an existing system you gain nothing.

[Carlos Ribeiro]

> > Besides that, Linux is Posix compliant and emulates Unix

system calls to a large extend, and that also makes C a
natural choice.

Not sure I follow on that point. Any low level language that
can deal with a C "struct" and byte-addressible memory would be
fine.

Well, Unix itself was written in C, and a good part of the C standard
library maps naturally to (or at least helps to implement) functions
that are mandatory in a Posix-compliant OS. This does not meant that
other languages cant be used; it only means that C is a natural
choice.

Of course, you can provide a C-like interface for a Python program
(for example). But a OS written in pure Python would make a much
better use of the language if it provides a Pythonic interface. I
believe we can agree on this point, dont you think?

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com

[Francis Lavoie]

Phil Frost wrote:

On Wed, Oct 13, 2004 at 08:24:48PM -0300, Carlos Ribeiro wrote:

...

Now, let me re-state your question in a broader sense. Is it possible
to write an OS using a language such as Python? Yes. But the resulting
OS will surely be different from Linux -- by design it would be a
completely different beast. Some parts would still be written in C and
assembler, because it needs to access the hardware, and also for
performance reasons. But an API could be devised to allow higher-level
functions to be written in Python, while calling the low-level
C+assembler stuff. But as I said, it's _so_ completely different from
anything else in use today as to make it pretty much a theorethical or
academic exercise with little practical use. I can't see a project
like that taking off, even if I would love to see it working.

I can state from first-hand experience that this idea is not too
far-fetched. It is possible to enable Python to express device drivers
and low level OS functions like multitasking with an amazingly small
amount of C+asm; I'd say around 2000 lines, excluding the Python
runtime. If Pyrex counts as not-C, then I bet it could be done in 500.

The performance problems are a bit harder, but with a good JIT compiling
VM the runtime performance of Python could theoretically come very close
to C.

I do agree though that there is little point in rewriting Linux in
Python. The advantage in Python is its expressiveness, but by rewriting
an existing system you gain nothing.

unununium, except is name, look very amazing ... but we still have to
wait to see a product.

[Grant Edwards]

On 2004-10-14, Carlos Ribeiro <ca********@gmail.com> wrote:

Besides that, Linux is Posix compliant and emulates Unix
system calls to a large extend, and that also makes C a
natural choice.
Not sure I follow on that point. Any low level language that
can deal with a C "struct" and byte-addressible memory would be
fine.

Well, Unix itself was written in C,

Originally it wasn't, but recent versions are.
and a good part of the C standard library maps naturally to
(or at least helps to implement) functions that are mandatory
in a Posix-compliant OS.
True, but that has nothing to do with writing a kernel. When
working in kernel space, you don't have access to Posix
services or the standard C library. Since you can't use the
standard C library when writing a kernel, it doesn't matter
what language it was designed for. Likewise for any of the
Posix standards that specify the API between an application and
the system libraries.
This does not meant that other languages cant be used; it only
means that C is a natural choice.
I still don't see why.
Of course, you can provide a C-like interface for a Python program
(for example). But a OS written in pure Python would make a much
better use of the language if it provides a Pythonic interface. I
believe we can agree on this point, dont you think?

Not really -- the interace between the kernel and user-space
isn't particulary C-oriented. IIRC on the x86 platform, you
make a system call by loading values into registers and
executing an interrupt instruction. You can't even make a
Linux system call on Linux using standard C. You have to use
assembly language wrappers that convert between the system call
API and the C API. It would be just as easy to make those
assembly language wrappers convert to a Pascal or Python API.

--
Grant Edwards grante Yow! Isn't this my STOP?!
at
visi.com

[Dennis Lee Bieber]

On Wed, 13 Oct 2004 15:32:01 -0700, Maboroshi <no****@hotmail.com>
declaimed the following in comp.lang.python:

Hello

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in python
basically just taking the source code from linux and rewriting it in
python Would this idea make sense to do - if so what would be the
benefits of doing this and in what way would this not be a good idea

You'd have to name the result Ouroborous...

After all, common Python relies on the C-library making OS level
I/O calls... (and the C-library may be relying on assembly modules yet).
If it were possible, it would run VERY slowly; you'd be using a
byte-code interpreter to perform what is normally highly optimized
native code.

-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

[Cliff Wells]

On Thu, 2004-10-14 at 01:44 +0000, Grant Edwards wrote:

On 2004-10-14, Carlos Ribeiro <ca********@gmail.com> wrote:

Besides that, Linux is Posix compliant and emulates Unix
system calls to a large extend, and that also makes C a
natural choice.

Not sure I follow on that point. Any low level language that
can deal with a C "struct" and byte-addressible memory would be
fine.

Well, Unix itself was written in C,

Originally it wasn't, but recent versions are.

'Recent' meaning since 1974? ;)

--
Cliff Wells <cl************@comcast.net>

[Neal D. Becker]

Maboroshi wrote:

Hello

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in python
basically just taking the source code from linux and rewriting it in
python Would this idea make sense to do - if so what would be the
benefits of doing this and in what way would this not be a good idea

Cheers

Yeah, that's a great idea. Go for it. Let me know when you're done.

[Miki Tebeka]

Hello Carlos,

[Maboroshi]

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in python

[Carlos] I can't see a project like that taking off, even if I would love to see
it working.

In a diffrent language, MzScheme can boot as an OS on x86
(http://www.ccs.neu.edu/scheme/packages/mzscheme/) using OSKit
(http://www.cs.utah.edu/flux/oskit/)

Bye.
--
------------------------------------------------------------------------
Miki Tebeka <mi*********@gmail.com>
http://tebeka.spymac.net
The only difference between children and adults is the price of the toys

[Michael Hobbs]

Maboroshi <no****@hotmail.com> wrote:

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in python
basically just taking the source code from linux and rewriting it in
python Would this idea make sense to do - if so what would be the
benefits of doing this and in what way would this not be a good idea

I had once given serious thought to what it would take to write an OS only
in a high-level language. (Standard ML was my language of choice at the
time.) The short answer is, no, it can't be done with Python as it currently
stands.

First, you would need a Python compiler that can compile Python programs to
machine code. Otherwise, what would you write your interpreter in? Python?
What would you write the interpreter's interpreter in? It can't be Python
all the way down. (Turtles are a different story, though. ;)

Second, in order to communicate with hardware, you would need modifications
to the Python language so that you can read and write bytes to specific
memory locations. You would also need to be able to signal interrupts. Plus,
you would also need to be able get the exact memory location of functions,
in order register interrupt handlers.
-- Michael Hobbs

[Grant Edwards]

On 2004-10-14, Cliff Wells <cl************@comcast.net> wrote:

On Thu, 2004-10-14 at 01:44 +0000, Grant Edwards wrote:

On 2004-10-14, Carlos Ribeiro <ca********@gmail.com> wrote:

>>> Besides that, Linux is Posix compliant and emulates Unix
>>> system calls to a large extend, and that also makes C a
>>> natural choice.
>>
>> Not sure I follow on that point. Any low level language that
>> can deal with a C "struct" and byte-addressible memory would be
>> fine.
>
> Well, Unix itself was written in C,

Originally it wasn't, but recent versions are.

'Recent' meaning since 1974? ;)

Yup. I admit that was sub-optimal phrasing. I should have
said something more like "The first version wasn't but the rest
were."

--
Grant Edwards grante Yow! Did you find a
at DIGITAL WATCH in YOUR box
visi.com of VELVEETA??

[Grant Edwards]

On 2004-10-14, Michael Hobbs <mi**@hobbshouse.org> wrote:

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in python
basically just taking the source code from linux and rewriting it in
python Would this idea make sense to do - if so what would be the
benefits of doing this and in what way would this not be a good idea

I had once given serious thought to what it would take to write an OS only
in a high-level language. (Standard ML was my language of choice at the
time.) The short answer is, no, it can't be done with Python as it currently
stands.

First, you would need a Python compiler that can compile Python programs to
machine code. Otherwise, what would you write your interpreter in? Python?

Silicon. ;)

--
Grant Edwards grante Yow! Vote for ME
at -- I'm well-tapered,
visi.com half-cocked, ill-conceived
and TAX-DEFERRED!

[Jeremy Bowers]

On Thu, 14 Oct 2004 15:32:49 +0000, Grant Edwards wrote:

On 2004-10-14, Michael Hobbs <mi**@hobbshouse.org> wrote:

First, you would need a Python compiler that can compile Python programs to
machine code. Otherwise, what would you write your interpreter in? Python?

Silicon. ;)

"Forgive him, Father Intel, for he knows not for what he asks."

(OK, I think you do, but I couldn't resist. :-) )

[Carlos Ribeiro]

On 14 Oct 2004 01:44:29 GMT, Grant Edwards <gr****@visi.com> wrote:

This does not meant that other languages cant be used; it only
means that C is a natural choice.

I still don't see why.

Of course, you can provide a C-like interface for a Python program
(for example). But a OS written in pure Python would make a much
better use of the language if it provides a Pythonic interface. I
believe we can agree on this point, dont you think?

Not really -- the interace between the kernel and user-space
isn't particulary C-oriented. IIRC on the x86 platform, you
make a system call by loading values into registers and
executing an interrupt instruction. You can't even make a
Linux system call on Linux using standard C. You have to use
assembly language wrappers that convert between the system call
API and the C API. It would be just as easy to make those
assembly language wrappers convert to a Pascal or Python API.

Now I see your point. It remembers me a little bit about the
discussions between GNU/Stallman and Linux/Linus on what makes a OS.
The kernel is one thing, the OS is another beast. I still think that a
language such as Python can be used to write the OS -- in the sense
where the name Linux is usually called upon (even if technically
incorrect, as the GNU/Stallman camp would quickly point out); it
includes high level APIs, much above the low-level kernel calls . But
the kernel itself is the hard part for a high level language.

As for C being a natural choice as far as the kernel part is
concerned... it may be because it compiles to efficient code, or
because it facilitates integration with assembler, or because it can
efficiently uses registers... Who knows? But the main reason is
probably simple: it's because everyone is just used to it.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com

[Caleb Hattingh]

That's a very sarcastic reply.

The question, really, is what the effect would be of writing an OS in a
HLL (particularly on speed of development, bug-fixes, and feature
addition).

I think that is worth asking.

Granted, as a minimum Python would need to compile to native machine code
(or interface with a really detailed native virtual machine) but I expect
(hope!) that is going to get done anyway.
On Thu, 14 Oct 2004 08:53:54 -0400, Neal D. Becker <nd*******@verizon.net>
wrote:

Maboroshi wrote:

Hello

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in python
basically just taking the source code from linux and rewriting it in
python Would this idea make sense to do - if so what would be the
benefits of doing this and in what way would this not be a good idea

Cheers

Yeah, that's a great idea. Go for it. Let me know when you're done.

[Grant Edwards]

On 2004-10-14, Carlos Ribeiro <ca********@gmail.com> wrote:

As for C being a natural choice as far as the kernel part is
concerned... it may be because it compiles to efficient code,
or because it facilitates integration with assembler, or
because it can efficiently uses registers...
All of those.
Who knows? But the main reason is probably simple: it's
because everyone is just used to it.

Exactly. Any number of "low level", statically typed,
compiled, languages would work equally as well. Modula-2 (not
sure about M-3, the GC stuff maybe a bit iffy in a kernel),
Ada, BLISS, PL/I, Pascal, etc.

--
Grant Edwards grante Yow! I feel like I'm
at in a Toilet Bowl with a
visi.com thumbtack in my forehead!!

[Mike Meyer]

mi**@hobbshouse.org (Michael Hobbs) writes:

Maboroshi <no****@hotmail.com> wrote:

My question has to do with python and linux - I was interested in
finding out what it would take to reimplement the Linux Kernel in python
basically just taking the source code from linux and rewriting it in
python Would this idea make sense to do - if so what would be the
benefits of doing this and in what way would this not be a good idea I had once given serious thought to what it would take to write an OS only
in a high-level language. (Standard ML was my language of choice at the
time.) The short answer is, no, it can't be done with Python as it currently
stands.

But it can be done. It *has* been done.
First, you would need a Python compiler that can compile Python programs to
machine code. Otherwise, what would you write your interpreter in? Python?
What would you write the interpreter's interpreter in? It can't be Python
all the way down. (Turtles are a different story, though. ;)
If you've got a Python compiler that generates machine code, you most
certainly *can* write your Python interpreter in Python. That's the
way most LISP systems are built.
Second, in order to communicate with hardware, you would need modifications
to the Python language so that you can read and write bytes to specific
memory locations. You would also need to be able to signal interrupts. Plus,
you would also need to be able get the exact memory location of functions,
in order register interrupt handlers.

Actually, you don't need those modifications to Python. What you need
is a module written in something other than Python that lets you do
all those things. All unix systems I'm aware of require code in
something other than C to let them do things that C can't do. Nothing
wrong about this - it's just the nature of the beast.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Michael Hobbs]

Mike Meyer <mw*@mired.org> wrote:

mi**@hobbshouse.org (Michael Hobbs) writes:

I had once given serious thought to what it would take to write an OS
only in a high-level language. (Standard ML was my language of choice
at the time.) The short answer is, no, it can't be done with Python as
it currently stands.

But it can be done. It *has* been done.
[snip]
Actually, you don't need those modifications to Python. What you need
is a module written in something other than Python that lets you do
all those things.

Sorry, I should have emphasized the word *only*. I'm talking about writing
an OS *only* with Python. No C, no assembly, just Python. Writing an OS
without assembly would be impossible unless the compiler can somehow map
required processor opcodes to a function or statement in the higher-level
language. Python does not currently have a proper compiler, much less
functions or statements that would, say, put the processor into protected
mode.

-- Michael Hobbs

[Cliff Wells]

On Thu, 2004-10-14 at 15:31 +0000, Grant Edwards wrote:

On 2004-10-14, Cliff Wells <cl************@comcast.net> wrote:

On Thu, 2004-10-14 at 01:44 +0000, Grant Edwards wrote:

On 2004-10-14, Carlos Ribeiro <ca********@gmail.com> wrote:

> Well, Unix itself was written in C,

Originally it wasn't, but recent versions are.

'Recent' meaning since 1974? ;)

Yup. I admit that was sub-optimal phrasing. I should have
said something more like "The first version wasn't but the rest
were."

And I thought you were just showing your age ;)

--
Cliff Wells <cl************@comcast.net>

[Grant Edwards]

On 2004-10-15, Cliff Wells <cl************@comcast.net> wrote:

Originally it wasn't, but recent versions are.

'Recent' meaning since 1974? ;)

Yup. I admit that was sub-optimal phrasing. I should have
said something more like "The first version wasn't but the rest
were."

And I thought you were just showing your age ;)

Nah, I'm not quite that old -- my Unix experiece only goes back
20 years to the days of v7 on a PDP11.

--
Grant Edwards grante Yow! I Know A Joke!!
at
visi.com

[Bengt Richter]

On Fri, 15 Oct 2004 00:37:39 -0000, mi**@hobbshouse.org (Michael Hobbs) wrote:

Mike Meyer <mw*@mired.org> wrote:

mi**@hobbshouse.org (Michael Hobbs) writes:

I had once given serious thought to what it would take to write an OS
only in a high-level language. (Standard ML was my language of choice
at the time.) The short answer is, no, it can't be done with Python as
it currently stands.

But it can be done. It *has* been done.
[snip]
Actually, you don't need those modifications to Python. What you need
is a module written in something other than Python that lets you do
all those things.

Sorry, I should have emphasized the word *only*. I'm talking about writing
an OS *only* with Python. No C, no assembly, just Python. Writing an OS
without assembly would be impossible unless the compiler can somehow map
required processor opcodes to a function or statement in the higher-level
language. Python does not currently have a proper compiler, much less
functions or statements that would, say, put the processor into protected
mode.

OTOH, it's a bootstrapping process. You can start by putting together
a python string that contains an image of the boot block on a bootable floppy,
and with suitable permissions you can write it to an actual floppy.

Next you can create a python string that is the image of a boot loader, that
the boot block will know where to find and read into memory using BIOS, if you
put it in a certain place on the floppy. And then you can get the loader to load
your OS image, which is a big bunch of bytes. You might want to structure the floppy
info for access as a primitive (non-patent-infringing ;-/) file system.
Maybe you will want to do a bootable CD instead ;-)

Anyway, CPU instructions are just bytes. As a start, it might be interesting to try to build
a dll extension in an mmap array and import it (be prepared for lots of crashes ;-).

Obviously mmap etc depend on the OS, but if you had prepared a suitable bootable OS
with a primitive file system and mmap functionality, and a userland python VM, ... well,
it's involved, but you can get there. I'd bet pypy will eventually be at the center of
something like that, with maybe a monolithic boot image in flash, and BIOS to boot it.
At some point, on a suitable platform, it will be able to self-host its own development, I'd bet.

Regards,
Bengt Richter

[Alex Martelli]

Phil Frost <in****@bitglue.com> wrote:
...

I do agree though that there is little point in rewriting Linux in
Python. The advantage in Python is its expressiveness, but by rewriting
an existing system you gain nothing.

By rewriting any existing system in a higher-level language, you may
gain the benefits of higher-level languages -- more concise and readable
expression, enabling maintenance, modification and enrichment.

This is certainly the advantage we're after with the pypy project, which
is based on rewriting the Python interpreter in Python. Google for
pypy, you'll find lots of materials about it on the net. If we can
shrink the interpreter and built-in modules from about 350K lines of
code (based on a rough find/xargs cat/wc on the 2.4 release) down to
about 30k (and we're on target for that -- pypy isn't anywhere like
ready, but already does a lot), the benefits in maintenance, further
future modification, enabling experimentations, etc, should follow.

Re Linux, we just got a fascinating talk at CodeJam Italia, last week,
about the new virtual memory twists that are likely going to be in
kernel 2.6.9. Part of it was this Indian mathematician appearing out of
nowhere with a wonderful new algorithm designed exactly to solve some
subtle problems in the new ("pagetable-less", pardon the
oversimplification!-) architecture for mmap on huge-memory machines.
This is wonderful, BUT, if the source could shrink by a factor of 10 or
more, making them hugely more accessible, think of how much more such
useful, nay, precious, contributions, that might elicit -- and how much
easier it would be for contributors to experiment and play around with a
huge variety of ideas...

The obvious problem might be performance. For that, all of us in the
pypy project (except the few others who can actually follow what's going
on;-) rely on wizard Armin Rigo, of psyco fame -- the idea is that the
pypy framework will "easily" (ha!-) generate machine code (on the fly or
in advance) for the (runtime-restricted) subset of Python which is used
in "interpreter level"... leading in the end to a _faster_ virtual
machine, wrt current pure-C Python, one competitive with CPython+psyco
or even beating it (thanks to advances in "symbolic execution" and type
annotation which are already enabled by using a higher-level language,
rather than C, for the interpreter/VM/execution framework).

pypy still needs to be completed, and proven in the field. But I'm
offering it as an example of the potential benefits of rewriting
existing software in higher-level languages...
Alex

[Mike Meyer]

Grant Edwards <gr****@visi.com> writes:

Exactly. Any number of "low level", statically typed,
compiled, languages would work equally as well. Modula-2 (not
sure about M-3, the GC stuff maybe a bit iffy in a kernel),
Ada, BLISS, PL/I, Pascal, etc.

Haven't operating systems been written in most of those languages? For
a sufficiently loose definition of OS, of course.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Grant Edwards]

On 2004-10-15, Mike Meyer <mw*@mired.org> wrote:

Grant Edwards <gr****@visi.com> writes:

Exactly. Any number of "low level", statically typed,
compiled, languages would work equally as well. Modula-2 (not
sure about M-3, the GC stuff maybe a bit iffy in a kernel),
Ada, BLISS, PL/I, Pascal, etc.
Haven't operating systems been written in most of those languages?

Sure. They weren't Unix, but a kernel's a kernel. :)
For a sufficiently loose definition of OS, of course.

VMS was mostly in BLISS, I believe. I think MacOS (and maybe
parts of MS-Windows way back when) were written in Pascal. I'm
sure IBM must have written at least one OS in PL/I (whether it
escaped into the wild or not, I don't know). I _think_ Intel
wrote iRMX in PL/M (a PL/I derivitive). I can't think of any
OSes written in Modula-[23] off the top of my head.

--
Grant Edwards grante Yow! My FAVORITE group
at is "QUESTION MARK & THE
visi.com MYSTERIANS"...

[Paul Rubin]

Mike Meyer <mw*@mired.org> writes:

Haven't operating systems been written in most of those languages? For
a sufficiently loose definition of OS, of course.

I'm amazed no one has mentioned the Lisp machine.

[Mike Meyer]

Grant Edwards <gr****@visi.com> writes:

On 2004-10-15, Mike Meyer <mw*@mired.org> wrote:

Grant Edwards <gr****@visi.com> writes:

Exactly. Any number of "low level", statically typed,
compiled, languages would work equally as well. Modula-2 (not
sure about M-3, the GC stuff maybe a bit iffy in a kernel),
Ada, BLISS, PL/I, Pascal, etc.

Haven't operating systems been written in most of those languages?

VMS was mostly in BLISS, I believe. I think MacOS (and maybe
parts of MS-Windows way back when) were written in Pascal. I'm
sure IBM must have written at least one OS in PL/I (whether it
escaped into the wild or not, I don't know). I _think_ Intel
wrote iRMX in PL/M (a PL/I derivitive). I can't think of any
OSes written in Modula-[23] off the top of my head.

DECWRL was heavy into both Modula and new machines/OS's. I'd be
surprised if they didn't write at least one OS in Modula.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Rod Haper]

Mike Meyer wrote:

Grant Edwards <gr****@visi.com> writes:

On 2004-10-15, Mike Meyer <mw*@mired.org> wrote:

Grant Edwards <gr****@visi.com> writes:

Exactly. Any number of "low level", statically typed,
compiled, languages would work equally as well. Modula-2 (not
sure about M-3, the GC stuff maybe a bit iffy in a kernel),
Ada, BLISS, PL/I, Pascal, etc.

Haven't operating systems been written in most of those languages?

VMS was mostly in BLISS, I believe. I think MacOS (and maybe
parts of MS-Windows way back when) were written in Pascal. I'm
sure IBM must have written at least one OS in PL/I (whether it
escaped into the wild or not, I don't know). I _think_ Intel
wrote iRMX in PL/M (a PL/I derivitive). I can't think of any
OSes written in Modula-[23] off the top of my head.

DECWRL was heavy into both Modula and new machines/OS's. I'd be
surprised if they didn't write at least one OS in Modula.

<mike

Hermes was a real-time OS written in Modula-2. The Lilith workstation
used Modula-2 as the system language but the lowlevel OS was in microcode.

SPIN was a UNIX-like research OS written in Modula-3. There are
probably others.

The Oberon OS is written in Oberon the Modula successor.

Operating systems written in the Modula family (including Oberon) tend
to merge the OS with the application level probably due the influence of
Wirth's ideas. They are more like operating environments.
--
Rod

[Dennis Lee Bieber]

On Fri, 15 Oct 2004 17:13:12 -0500, Mike Meyer <mw*@mired.org> declaimed
the following in comp.lang.python:

Grant Edwards <gr****@visi.com> writes:

Exactly. Any number of "low level", statically typed,
compiled, languages would work equally as well. Modula-2 (not
sure about M-3, the GC stuff maybe a bit iffy in a kernel),
Ada, BLISS, PL/I, Pascal, etc.
Haven't operating systems been written in most of those languages? For
a sufficiently loose definition of OS, of course.

Ada was spec'd for use on embedded systems -- with no OS; so it
is full of constructs for specifying the size of a data field, the
address of the data field, etc. (allowing access to memory mapped I/O
hardware, for example). Even the multi-tasking was supposed to be part
of the language run-time library. Most current compilers (or, at least,
GNAT) short-cut this by using OS level tasking features and I/O (via a
wrapper of the C runtime library).

BLISS was DEC's systems programming language. As such, it too
offered direct hardware capability -- at least on the same level as C
(shove a hardware address into a long int, then use it as a
pointer)(probably with link options for absolute addressing rather than
virtual).

I've not looked at PL/I; as I recall from the short coverage in
college, PL/I had a reputation of taking features from Algol, FORTRAN,
COBOL, and anything else available... No doubt it too had a means of
direct hardware access.

Not sure if Pascal had the ability; not as originally defined
(the teaching language, not the extended mutants that made it into
industry).

<mike
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

[Bengt Richter]

On Fri, 15 Oct 2004 02:07:52 GMT, bo**@oz.net (Bengt Richter) wrote:
[... maybe misleading lack of mention of benefits of compatibility with existing stuff ;-) ...]

Anyway, CPU instructions are just bytes. As a start, it might be interesting to try to build
a dll extension in an mmap array and import it (be prepared for lots of crashes ;-).

Obviously mmap etc depend on the OS, but if you had prepared a suitable bootable OS
with a primitive file system and mmap functionality, and a userland python VM, ... well,
it's involved, but you can get there. I'd bet pypy will eventually be at the center of
something like that, with maybe a monolithic boot image in flash, and BIOS to boot it.
At some point, on a suitable platform, it will be able to self-host its own development, I'd bet.

An OS in the larger sense is of course more than a kernel and some primitives, and even if it
is feasible to re-implement all kinds of utility functions in a new language, it is not very
practical[1] replace a lot of stuff except as a slow migration, happening in cases where someone
would rather rebuild than remodel. So then you wind up asking how to make your bootstrapped OS
able to run legacy binaries, or relink legacy object files with your newly-implemented primitive
libraries, and then whose linker you want to have do that, and how to execute *that* etc. So you
will probably either adopt a standard existing ABI or build some adaptation layer for your kernel
that provides it. Anyway, I just wanted to mention that I think there is enormous mass and inertia
in the way legacy tools and applications are represented in various format files, and it takes
a long time for something new to take hold. And a kludge that works to accomplish a money-making-critical
task today pretty much beats any vision for tomorrow, until someone has a new today thing ready
to compete in the tomorrow. Even then, the tendency is for the new to contain a 1401 emulator or such ;-/
[1] Of course, practicality may beat purity, but fun beats practicality ;-)

Regards,
Bengt Richter