new language for kernel/embedded system programming - Minix

This is a discussion on new language for kernel/embedded system programming - Minix ; I learned programming in C and Java. I have come to appreciate OOD as well as OOP. I feel the newer generation of programmers in general have more liking/comfort for both OOD and OOP. With MINIX kernel/servers I really appreciate ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: new language for kernel/embedded system programming

  1. new language for kernel/embedded system programming

    I learned programming in C and Java. I have come to appreciate OOD as
    well as OOP. I feel the newer generation of programmers in general have
    more liking/comfort for both OOD and OOP.

    With MINIX kernel/servers I really appreciate the way it is designed.
    But I miss the cleanliness of implementation as in OOP (specifically
    Java syntax).

    AST has discussed in one line about C,C++ and Java in the book. He
    rejected Java on basis of lack of manual memory management and
    uncertainties in garbage collection timings.

    This set me into thinking of making a Java like language with following
    features -
    -- compiles to native binary (exe)
    -- has 'delete' operator (for manual memory management)
    -- classes to have destructors
    -- object creation on stack (for fast execution)
    e.g.
    void stackObject()
    {
    Arguments stackOjb; // reference only
    Arguments heapObj = new Arguments(); // heap

    stackOjb = Arguments(); // stack object created

    delete(heapObj); // heap object deletion to be permitted
    } // stackObj to be destroyed when this function end


    -- object reference as an absolute address
    (e.g.
    class RegisterSet
    {
    byte[4] RegisterSet;
    void foo(){ // something}
    }
    void somefunc()
    {
    RegisterSet hardware = 0x378; // device address
    hardware.foo();
    }
    // end-of-example
    - inline assembly or function import/export from assembly
    void func{
    assembly{
    mov %esp, %ebp;
    ...........
    }
    }

    The usage of this language is specifically targeted for Kernel/Device
    Drivers/Embedded system programming.

    I am short on both - kernel expertise as well as compiler construction.

    I invite constructive criticism or suggestions on what issues will come
    with this language and kernel implementation in such language.


  2. Re: new language for kernel/embedded system programming

    I think that this discussion is probably off-topic for c.o.m. Not sure
    where else it should go, though.

    On Tue, 10 Oct 2006 23:12:07 -0700, SKS wrote:

    > I learned programming in C and Java. I have come to appreciate OOD as
    > well as OOP. I feel the newer generation of programmers in general have
    > more liking/comfort for both OOD and OOP.


    There's lots of OOD in modern operating systems, even in Minix. It's
    considered a good idea to keep design and programming separate exercises,
    in some circles. It has at least the advantage that some design might
    happen before the programming.

    > With MINIX kernel/servers I really appreciate the way it is designed.
    > But I miss the cleanliness of implementation as in OOP (specifically
    > Java syntax).


    Java syntax is not clean. Sure, it's cleaner than C++, but it's got knobs
    on, compared to Algol-school languages like Oberon, Modula-3, Ada and
    Eiffel. (There are plenty who would argue that those, in turn, have knobs
    on compared to Smalltalk, or functional languages of the lisp and ml
    schools.)

    > AST has discussed in one line about C,C++ and Java in the book. He
    > rejected Java on basis of lack of manual memory management and
    > uncertainties in garbage collection timings.


    That's not a great argument: malloc and free generally have indeterminate
    timings, too. OS kernels tend not to use malloc and free, though. Only
    static allocation is predictable, and you can do that in Java, sort-of,
    but it's much harder to do it in Java than in C if you use any of the
    standard library, as it has a tendancy for methods to return newly
    allocated objects, rather than operating on pre-existing (static, perhaps)
    allocations.

    > This set me into thinking of making a Java like language with following
    > features -
    > -- compiles to native binary (exe)


    Modula-3, Ada and Eiffel do that. I think that Oberon does too, but can't
    remember. Java can too, but you have to not use some features, like
    run-time object loading.

    > -- has 'delete' operator (for manual memory management) -- classes to
    > have destructors


    Whatever.

    > -- object creation on stack (for fast execution) e.g.


    You can't, in general, do that, unless you have a convention of copying
    objects out to the heap if there is any chance that a reference argument
    might find itself stored somewhere beyond the scope of the creating
    method. Modern JVM does some of this analysis, and puts objects that it
    can make these proofs for on the stack. Not sure whether a Java compiler
    like GCJ can do that, but it might.

    > -- object reference as an absolute address


    The Java used in at least one JavaOS project that I've seen a paper on
    achieved this without putting it into the language syntax, but by
    including a single special (natively implemented) "memory" class. From
    memory, class objects behaved like arrays, but creation methods took
    absolute start address arguments.

    > - inline assembly or function import/export from assembly


    Dunno about that. It doesn't help with portability. Better to use whole
    assembly-language functions that can be selectable for the platform, where
    necessary, and provide an external function-call mechanism.

    You might want to check out the "D" language
    (http://www.digitalmars.com/d/) It's probably much closer to what you're
    looking for than Java, and has the advantage of already existing.

    Cheers,

    --
    Andrew


  3. Re: new language for kernel/embedded system programming

    Your question might be more suited for the alt.os.development group,
    but since I've myself (way back in my misguided youth) considered
    designs on a Java-based operating system, I think I know where you're
    coming from...

    SKS wrote:
    > I learned programming in C and Java. I have come to appreciate OOD as
    > well as OOP. I feel the newer generation of programmers in general have
    > more liking/comfort for both OOD and OOP.
    >
    > With MINIX kernel/servers I really appreciate the way it is designed.
    > But I miss the cleanliness of implementation as in OOP (specifically
    > Java syntax).


    Object-oriented programming is by no means new, and it certainly isn't
    a silver bullet.

    It's worth noting that it is entirely possible to write object-oriented
    code in plain C. The Linux VFS layer is an example of this. Read
    "Linux: C++ In The Kernel?" (http://kerneltrap.org/node/2067) for a
    long debate with various viewpoints relevant to the discussion at hand.

    > This set me into thinking of making a Java like language with following
    > features -
    > -- compiles to native binary (exe)
    > -- has 'delete' operator (for manual memory management)
    > -- classes to have destructors
    > -- object creation on stack (for fast execution)


    Sounds to me like you're describing C++. Just a thought.

    > The usage of this language is specifically targeted for Kernel/Device
    > Drivers/Embedded system programming.


    For an example of an interesting project with these goals and more,
    have a look at http://www.coyotos.org/.

    > I am short on both - kernel expertise as well as compiler construction.
    >
    > I invite constructive criticism or suggestions on what issues will come
    > with this language and kernel implementation in such language.


    If you're serious about this, there are people who are, in fact,
    building Java-based operating systems. The most viable project seems to
    be JNode (http://www.jnode.org/).

    However, since I've been down this (in my opinion, very misguided)
    road, hopefully you can learn from my hindsight. Before committing to
    any such undertaking, I'd seriously recommend adding some important
    computer science concepts and key programming languages to your
    repertoire.

    For instance, to learn what object-oriented programming was originally
    intended to be, before it got popularly perverted by C++ and Java,
    learn Smalltalk (http://www.squeak.org/) or Ruby
    (http://www.ruby-lang.org/).

    Next, to more fully understand why Java is a mere early stepping stone
    (http://www.paulgraham.com/avg.html) on your way to hacker
    enlightenment, try and grok Lisp (http://lispers.org/) -- then perhaps
    you'll want to develop a modern Lisp Machine
    (http://pt.withy.org/publications/LispM.html) instead of a mere
    Java-like system ;-)

    Given your comment about compiler construction, another benefit of
    learning Lisp is that you'll quickly gain a solid understanding of how
    interpreters and compilers work. (The downside is that you won't want
    to work with Java any longer, which could be a problem, depending on
    your work description.)

    With your motivations, Squeak (http://www.squeak.org/) will likely be a
    great project to draw inspiration from (or better yet, contribute to),
    and it's certainly the current closest thing to a Lisp Machine-like
    environment where *everything* is a live object.

    I should probably add Forth to the list (especially given its
    suitability for firmware and device driver programming), but I suspect
    following through with the other aforementioned technologies will take
    a couple of years, as it is... ;-)

    Whatever you decide to do, it's sure to be an interesting journey. Good
    luck.

    --
    Arto Bendiken | arto.bendiken@gmail.com | http://bendiken.net/


  4. Re: new language for kernel/embedded system programming

    Nice idea, but...

    Every advantage you gain in a field, costs you disadvantage(s) in some,
    hopefully, other fields, I believe. It's the law of nature. As a result
    when we talk about design cleanness and implementation
    understandability, we should consider the drawbacks. SPEED! The key
    factor lost when over-focusing the implementation understandability.

    When it comes to OS implementation there are several key factors that
    an ideal OS must satisfy; speed, modularity, fault tolerance and least
    memory consumption, to name a few. However, obviously, no OS cannot
    satisfy all of them -Nothing is perfect, again another law of nature
    ;-). But as all of us agree, speed and short turnaround time are at the
    very heart of the design goals and also key concepts from the user's
    view. Imagin an OS in which network packets are lost when the load on
    the system rises up to a high value or an OS which requires a
    server-level hardware is required (Would you give it a try?! ;-)

    I believe that OOD is good -not the best as AOD is going to replace it-
    for business solutions but for OSes I would say that breaking the
    problem into small parts and make them modular and responsive to
    others' requests is the main concern, using whatever technology or
    methodology...but selecting the fastest -not usually the simplest and
    cleanest one. No matter, since OS developing is not a job done by
    ordinary developers or end users!

    Regards,

    Bahman


  5. Re: new language for kernel/embedded system programming

    SKS wrote:
    > I learned programming in C and Java. I have come to appreciate OOD as
    > well as OOP. I feel the newer generation of programmers in general have
    > more liking/comfort for both OOD and OOP.
    >
    > With MINIX kernel/servers I really appreciate the way it is designed.
    > But I miss the cleanliness of implementation as in OOP (specifically
    > Java syntax).
    >
    > AST has discussed in one line about C,C++ and Java in the book. He
    > rejected Java on basis of lack of manual memory management and
    > uncertainties in garbage collection timings.
    >
    > This set me into thinking of making a Java like language with following
    > features -
    > -- compiles to native binary (exe)
    > -- has 'delete' operator (for manual memory management)
    > -- classes to have destructors
    > -- object creation on stack (for fast execution)
    > e.g.
    > void stackObject()
    > {
    > Arguments stackOjb; // reference only
    > Arguments heapObj = new Arguments(); // heap
    >
    > stackOjb = Arguments(); // stack object created
    >
    > delete(heapObj); // heap object deletion to be permitted
    > } // stackObj to be destroyed when this function end
    >
    >
    > -- object reference as an absolute address
    > (e.g.
    > class RegisterSet
    > {
    > byte[4] RegisterSet;
    > void foo(){ // something}
    > }
    > void somefunc()
    > {
    > RegisterSet hardware = 0x378; // device address
    > hardware.foo();
    > }
    > // end-of-example
    > - inline assembly or function import/export from assembly
    > void func{
    > assembly{
    > mov %esp, %ebp;
    > ...........
    > }
    > }
    >
    > The usage of this language is specifically targeted for Kernel/Device
    > Drivers/Embedded system programming.
    >
    > I am short on both - kernel expertise as well as compiler construction.
    >
    > I invite constructive criticism or suggestions on what issues will come
    > with this language and kernel implementation in such language.


    This seems cool for your mentioned porposes; just remember that
    "typing" is the bane of lazy coders

    dont stop!


  6. Re: new language for kernel/embedded system programming

    You know, I took a course on advanced (Java) programming in High
    School, and we had to do a final project. So I worked with my friend on
    making an OS and we (being the young, naive programmers we were) tried
    doing in with Java bytecode! Well, needless to say, we didn't
    succeed...we submitted a simple assembly code program that loops my
    name and this other fellow's name and "are cool".

    Anyways, I would think that what you are doing is creating a modified
    form of C# such that you could incorporate pointers/references, and so
    forth. Might I add the suggestion for your programming language (SKS is
    actually a keen name for a programming language, come to think of it)
    compile to C-- so it would have the advantage of portability? (You
    might want to scratch that since C-- compilers aren't ported to a large
    number of architectures, I'm not sure.)

    Heck, you could even write the compiler in Java so it could
    theoretically be ported from system to system without much of a hassle.

    Also I would think if you were writing this especially for operating
    systems programming, you should allow the programmer to enter assembly
    code directly (just as C# allows the programmer to manage memory
    manually, albeit in an "unsafe" area).

    But also bear in mind you _CAN_ do OOP in ANSI C! Yes, it's true! And
    without the use of Objective C! Take a look at Phil's Guide to OO ANSI
    C (http://www.bolthole.com/OO-C-programming.html). Just something to
    think about.

    I would suggest that you study the dragon book
    (http://en.wikipedia.org/wiki/Compile...s%2C_and_Tools)
    religiously if you are serious about this. And for studying operating
    system design and implementation, I would suggest you buy the book
    "Operating Systems: Design and Implementation" and study that and the
    source code for minix religiously.

    That is how I would approach it anyways, good luck!


  7. Re: new language for kernel/embedded system programming

    > You might want to check out the "D" language
    > (http://www.digitalmars.com/d/) It's probably much closer to what you're
    > looking for than Java, and has the advantage of already existing.


    Thanks a lot for your suggestion. I spent some time with D language.
    This had most of the things I desired - compile to native, removal of
    preprocessor, inline assembly, manual memory management etc.

    Only few minor deviations from my model of kernel programming lang like
    optional bounds check. default behaviour of language to put array
    bounds-check and by using "unbounded" this can be switched off.
    something like :

    int[10] array; // during development
    unbounded int[10] array; // in production

    The default behaviour would give quick development and after module is
    stable then unbounded can be applied for performance boost.

    I believe C++ was targeting too much - kernel, system and applications.
    C was positioned better - kernel and system. Java cleaned up C++ but
    took it to the aplication. D also cleans up C++ but keeps it close to
    system. For kernel programming in D I will be exploring further.


  8. Re: new language for kernel/embedded system programming


    Pablo Rodriguez wrote:

    > > But also bear in mind you _CAN_ do OOP in ANSI C! Yes, it's true! And

    > without the use of Objective C! Take a look at Phil's Guide to OO ANSI
    > C (http://www.bolthole.com/OO-C-programming.html). Just something to
    > think about.


    It's a just comment.
    OOP is more than that. Cenceptually, they functions simillalry, but
    more hidden code (runtime libraris) to virtualize the shared memory
    runtime system is implemented. When it works only in stand-alone
    computer, they looks like they have no difference. When it is extended
    to distributed sytems, it has more functions. OOP is partially
    orignated from shared-memory system. So it can't be talked excluding
    shared-momory. In addition, synchronization concept within shared
    momory is integrated to realize more modularity like thread-safe
    functions. It is a good news for programmers because they don't have to
    worrry about "dirty jobs" under the cover.


  9. Re: new language for kernel/embedded system programming

    SKS wrote:
    > I learned programming in C and Java. I have come to appreciate OOD as
    > well as OOP. I feel the newer generation of programmers in general have
    > more liking/comfort for both OOD and OOP.

    [...]
    > This set me into thinking of making a Java like language with following
    > features -
    > -- compiles to native binary (exe)
    > -- has 'delete' operator (for manual memory management)
    > -- classes to have destructors
    > -- object creation on stack (for fast execution)

    [...]
    > -- object reference as an absolute address

    [...]
    > - inline assembly or function import/export from assembly


    Haven't you just described C++?

    I mean, seriously, C++ has exactly the set of features you're asking for.
    Java-like syntax (actually, Java has C++-like syntax), native code generation,
    manual memory allocation, a rich set of OO features... why design a wholenew
    language?

    --
    +- David Given --McQ-+ "There is one thing a man must do // Before his
    | dg@cowlark.com | life is done; // Write two lines in APL // And make
    | (dg@tao-group.com) | the buggers run."
    +- www.cowlark.com --+ --- The Devil's DP Dictionary


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2.2 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFFLihBf9E0noFvlzgRAhOkAKDKbExKi9jGLdHf44AoVm dTWySucQCeP0iY
    hMZ+RcBiNDGiyOehUJeCzys=
    =gtQ1
    -----END PGP SIGNATURE-----


  10. Re: new language for kernel/embedded system programming

    In article <1160628372.057372.238790@m73g2000cwd.googlegroups. com>,
    SKS wrote:
    >
    >int[10] array; // during development
    >unbounded int[10] array; // in production
    >
    >The default behaviour would give quick development and after module is
    >stable then unbounded can be applied for performance boost.


    Do you drive without seatbelts after you've learned how to drive? A
    program in production still needs protection against everything the real
    world will throw at it, and that you didn't anticipate while testing.

    So keep the checks. Any good compiler will know that simple code like:

    for (i = 0; i < 10; i++) array[i] = 0;

    Doesn't need bounds checks on array[i] at all, and for less simple code
    it should be able to move most of the checks outside loops.

    If you still need a speedup then profile your code and optimize the
    inner loops or something.
    --
    Kees J. Bot, Systems Programmer, Sciences dept., Vrije Universiteit Amsterdam

  11. Re: new language for kernel/embedded system programming

    SKS wrote:
    > I learned programming in C and Java. I have come to appreciate OOD as
    > well as OOP. I feel the newer generation of programmers in general have
    > more liking/comfort for both OOD and OOP.
    >
    > With MINIX kernel/servers I really appreciate the way it is designed.
    > But I miss the cleanliness of implementation as in OOP (specifically
    > Java syntax).
    >
    > AST has discussed in one line about C,C++ and Java in the book. He
    > rejected Java on basis of lack of manual memory management and
    > uncertainties in garbage collection timings.
    >
    > This set me into thinking of making a Java like language with following
    > features -
    > -- compiles to native binary (exe)
    > -- has 'delete' operator (for manual memory management)
    > -- classes to have destructors
    > -- object creation on stack (for fast execution)
    > e.g.
    > void stackObject()
    > {
    > Arguments stackOjb; // reference only
    > Arguments heapObj = new Arguments(); // heap
    >
    > stackOjb = Arguments(); // stack object created
    >
    > delete(heapObj); // heap object deletion to be permitted
    > } // stackObj to be destroyed when this function end
    >
    >
    > -- object reference as an absolute address
    > (e.g.
    > class RegisterSet
    > {
    > byte[4] RegisterSet;
    > void foo(){ // something}
    > }
    > void somefunc()
    > {
    > RegisterSet hardware = 0x378; // device address
    > hardware.foo();
    > }
    > // end-of-example
    > - inline assembly or function import/export from assembly
    > void func{
    > assembly{
    > mov %esp, %ebp;
    > ...........
    > }
    > }
    >
    > The usage of this language is specifically targeted for Kernel/Device
    > Drivers/Embedded system programming.
    >
    > I am short on both - kernel expertise as well as compiler construction.
    >
    > I invite constructive criticism or suggestions on what issues will come
    > with this language and kernel implementation in such language.
    >


    Such a language should also allow programmers to be almost purely
    procedural or imperative in their coding, as a OS should be written in a
    language whose semantics closely match that of the host CPU.

    Create a CPU that supports OOP in it's machine language/assembler code,
    and a OOP language would be good for an OS for that CPU.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFFMrhpsjeOFtd+nycRAsLuAJ9as/Z0apyJ7VDaRJI6xD3Q2eFq2gCeO3XO
    gPt300WO+Oa73onbBJnkX0E=
    =hMGt
    -----END PGP SIGNATURE-----


+ Reply to Thread