C++ in the kernel

[Bakul Shah]

Alfred Perlstein <alfred at freebsd.org> wrote:
> * Garance A Drosehn <gad at FreeBSD.org> [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