From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 16:36:15 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2664116A419; Tue, 30 Oct 2007 16:36:15 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 7FACC13C4A7; Tue, 30 Oct 2007 16:36:14 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id E70665B30; Tue, 30 Oct 2007 09:36:13 -0700 (PDT) To: Alfred Perlstein In-reply-to: Your message of "Mon, 29 Oct 2007 22:58:40 PDT." <20071030055840.GS33488@elvis.mu.org> Date: Tue, 30 Oct 2007 09:36:13 -0700 From: Bakul Shah Message-Id: <20071030163613.E70665B30@mail.bitblocks.com> Cc: Poul-Henning Kamp , Garance A Drosehn , freebsd-arch@FreeBSD.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2007 16:36:15 -0000 Alfred Perlstein wrote: > * Garance A Drosehn [071029 22:50] wrote: > > ... > > It might be prudent to say we're building a new language patterned > > on something *other* than C++, just to make it clear that we won't > > be tied to whatever developments coem up in the world of C++. > ... > I think the right thing to do here is to identify the things we > need added to C++ and propose those to the standards. If they > are reasonable and useful then it should be something that > passes and we will wind up with something the industry uses > rather than some graduate project while Linux eclipses us > even further because they took something that worked. Listing what is needed seems like a good first step (though I don't know about C++). I don't know rolling one's own extensions is a good idea either but a discussion of needs can help in figuring out the right thing to do and provide a strong rationale for whichever solutions are chosen. Without identifying needs we will end up talking at cross purposes. These can be along several axes: - better debugging support - better profiling - better testing (code coverage etc.) - better runtime checking (e.g. null checking, assertions) - better static checking (e.g. coverity?) - support for better abstractions (e.g. critical sections, "objects") - better support for SMP ... I am *not* suggesting coming up with something that covers all of the above; this is just a way of classifying so that they can be evaluated in the context of given constraints. It may turn out that several different solutions will exist apart from any language extensions. For instance, rather than enhancing the language can one come up with a better structure (or design pattern) for a part of the OS? Can a transparent filter add code to implement something we want (for instance, code coverage)? Can one generate low level tests automatically from header or code files? Can code be generated automatically to enable heavy assertion checking on first signs of trouble but otherwise let the kernel run at fullspeed? Sort of like airbags that deploy on first impact! Is there a more detailed writeup of Poul's ideas on K language beyond what is on the wiki.freebsd.org/K? Reading it brings to mind Brinch Hansen's extensions to Pascal. The structured macro paper referenced on the K wiki page also seems rather interesting. A powerful macro facility needs to be well integrated with the language (much like Lisp or Scheme's macros) so that you can write for instance critical_section(lock) { ... bar: ... if (cond1) break; ... if (cond2) goto foo; ... if (cond3) goto bar; ... if (cond4) return; // from enclosing function ... } ... foo: and have it transform to vanilla C code that does proper unlocking on any exit. To a first approximation I think of them as compile time "functions" that take identifiers and code as arguments and return code. IMHO building in things like mutexes or critical region etc. in a language makes it far too special purpose and both the code & compiler less portable (if the low level code for a critical section needs to be different for a different architecture, you have to change the compiler). But a general purpose macro facility can allow you to build these and many other kinds of control abstractions and hence is more likely to be popular if done right. Coming up with something that is semantically well defined & integrates well with C can not be easy. All budding feature designers ought to read Tony Hoare's "Hints on programming language design". Still relevant after 33 years. Search for cb-p193-hoare.pdf. -- bakul