Re: Creating an operating system

From: Corey Murtagh (emonk_at_slingshot.no.uce)
Date: 05/25/04 

Date: Wed, 26 May 2004 09:08:22 +1200

RosalieM wrote:

>>The main difference between interpreted and compiled languages is
>>execution speed. An interpreted loop must be translated as many times
>>as it is passed through, but a compiled loop in translated only
>>once. The same applies to subroutines (functions) which are called
>>more than once.
>
> This cant be improved ?

All depends on what you mean by 'interpreted' and 'improved' :>

If your interpreter uses some intermediate representation of the line
you might get a speed increase by caching that intermediate.

Frex, let's say you're reading a line of source and tokenizing it, then
running the token stream through a parser. You might get a speed
increase by caching the tokenized representation so that you can skip
that step next time you hit that line. Of course you could just
pre-tokenize the whole source, but that might be expensive at runtime on
large sources.

Another option is to compile on-the-fly to an instruction format -
either native or virtual machine. This will almost certainly give much
faster execution on subsequent passes.

And if you're /really/ good (better than me :>) you could write an
optimizer for subsequent runs. I believe the TransMeta x86 emulation
code does something like that. It takes a 'source' (x86 machine code)
block and compiles it to native code for the TransMeta CPU, stores and
executes the compiled code. Each time it hits the same block it tries
the next in a series of optimizers on the block. Once a block has been
executed a number of times it should be quite close to optimal for the CPU.

I can imagine this being done for a language, but it's well beyond my
abilities to implement.

<snip>
>>IMHO, the operating system written in an interpreted language will
>>be very slow compared to the capability of the computer system.
<snip>
> Things have changed, speed is not a problem anymore compared to solidity,
> developpement time and ability to share code between programers.

The fact that CPUs are so much faster now than they were <x> years ago
is /no/ reason to write inefficiently. Writing an OS in an
interpreted-only language is most certainly inefficient, and likely to
be unusably slow. At the least you'll have to use a compiled language,
and probably a bunch of machine code, to handle high-frequency tasks and
intensive operations. Drivers need to be as efficient as you can get
them, as do various other parts of an OS.

An interpreted video driver? No thanks :>

>>Before C, it was customary to write the operating systems in
>>assembler alone. The O/S core cannot be written in any language
>>keeping the programmer far from the gory details of the actual
>>processing hardware. In my opinion, C is a good compromise
>>between a high-level language and pure machine code.
>
> It was 40 years ago granddad, dad, and son ...

The fact that C is 'old' (by whatever definition you want to place on
'old') is irrelevant. If anything it demonstrates that it has proved
useful enough that it hasn't been discarded in favor of something else.
  Until such time as a 'better' replacement comes along (for ALL
definitions of 'better'), C will remain.

>>PS. The DHCP protocol is not handled by the C library, but by a
>> separate daemon (system service) instead.
>
> My idea was that when RFC publish DHCP standard with such an OS they could
> publish code too.

In what language? For which platform?

Far better to publish specifications and algorithms that can be
implemented in whichever language & platform the implementor chooses.

>>There is no way to write the O/S networking code without
>>understanding the gory details of networking protocols involved:
>>been there - done that.
>
> All theses gory details makes confusion, tcp/ip is not the same for linux,
> freebsd, windows...but all followed same RFC !?

Yes... and no. They're all compatible (largely) 'on the wire', but
there are broad differences in their implementations.

<snip>

> Why is this needed anymore, it may be time to start new from new, but
> question is, is this not already done? what time is needed to make such an
> os ?

If you're talking about an OS to rival existing incumbants in the
marketplace... I'd start my guess at several man-years and go up from there. 

-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

Relevant Pages

  • Re: Creating an operating system
    ... If your interpreter uses some intermediate representation of the line ... Another option is to compile on-the-fly to an instruction format - ... faster execution on subsequent passes. ... I can imagine this being done for a language, ...
    (comp.os.linux.development.system)
  • Re: shell..an interpreter but whats an interpreter (help me clear these doubts please)
    ... today more than 99% of programming electronic processors and to interface ... When a C code is compiled it is translated to machine's language. ... An interpreter takes from a source code file individual statements which are then temporarily converted to machine code and executed and then discarded thus each statement in an interpreted source must be a 'standalone' operation. ... If you created a similar compiled executable to simply set a variable x with value 5 and ran that, on completion of the execution, x will have been created, set to 5 and then discarded at the end of the execution and is no longer available upon returning control to the shell. ...
    (comp.unix.shell)
  • Whats the problem with current languages? (was:Re: Kitchen sink library -- gap between scripting and
    ... I am looking at the wrong language. ... diverse libraries rather than specific implementations. ... What's so special about a vm or an interpreter then? ... > compile them, you can change every program with a text editor. ...
    (comp.os.linux.development.apps)
  • Re: Algorithm books for Ruby (was Re: Object-oriented solution to Tower of Hanoi)
    ... But where's the "machine" in an AST walker? ... sense the higher language code has to be compiled into an intermediary ... Ruby interpreter - not a Ruby virtual machine. ... Machine simply provides some form of virtual execution environments. ...
    (comp.lang.ruby)
  • Re: A simple interpreter
    ... >>> It's not actually an interpreter but rather a compiler, ... >>> shows well how to embed a different language in Common Lisp. ... >> I think there's a difference between Common Lisp and Scheme here. ... >> need you may as well compile the expression I would have thought. ...
    (comp.lang.lisp)