Oddly enough, I think this project to assimilate the linux kernel would be much more successful if all mention of Oberonish things are kept silent. The thing that the Linux community seems to embrace is yet another tiny C compiler. So, one possible way to begin the assimilation is to use a C to C translator on the kernel, and look for ways to simplify things. For example, I think the two constructs "const int x" and "int const x" are equivalent, but as Frasier and Hanson mention in the lcc book, the flexibility makes extra work for the compiler. It should be possible to instrument the compiler and look for total usage statistics, machine translate the source to use the dominate usage, and produce source for the kernel that only use one paradigm. This would result in a smaller, stricter grammar that describes the source, and hence a smaller faster compiler.
On Mon, Dec 20, 2010 at 10:51 AM, Wojtek Skulski <skulski{([at]})nowhere.xy
Robert:
Seasons Greeting to you as well!
FYI, I am now doing some Linux development. To this end I am reading the book on Linux kenel-mode drivers. There is a fair amount of material there on Linux kernel. I am amazed to read that the newest-greatest Linux technology is called "modules". These are loaded/unloaded by the kernel. They have init and close sections, as well as methods. Sounds familiar?
On closer reading it is all Oberon-1. The methods are installed in procedure variables. There is no type safety anywhere. If you install a wrong pointer then kaboom. The compiler can barely help. Ditto with memory management. There are all kinds of addresses (virtual, kernel, user, etc), but all are being cast to "unsigned long". It is up to you to know which address is which. If you get lost in a maze of rules (which are changing from release to release) then your program will trap on wrong address at run time. If it happens in the kernel-mode code, then you computer will crash and you can then analyze register dumps.
So deep inside the newest-greatest Linux kernel 2.6.xxx is in fact an old original Oberon System with Oberon-1 run-time methods, but without Oberon type safety. All is arranged on top of old original C. The entire module structure is implemented by hand with a set of rules and preprocessor macros.
Amazing, how the newest-greatest and most advertised turns out to be old Wirth/Gutknecht design. Without proper attribution of course.
Greetings to all!
Wojtek
On Sun, 19 Dec 2010, Robert wrote:
As it turns out, the "Disambiguated glommable expression templates" did
not end in 1997. A more recent version is available:
http://adtmag.com/articles/2000/04/25/disambiguated-glommable-expression-templates-reintroduced.aspx
Wojtek,
I shall keep this reference for some light reading next April 1st.
Seasons Greetings
Regards
Robert
----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy--
Aubrey McIntosh, Ph.D.
1502 Devon Circle
Austin TX 78723-1814
http://home.grandecom.net/~amcintosh/aubrey/Search/
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
Received on Tue Mar 29 2011 - 17:55:37 UTC