On Sat, Jul 27, 2013 at 7:37 PM, David Jeske <[email protected]> wrote:
> On Sat, Jul 27, 2013 at 10:29 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> >> 1. Is a *great* general-purpose language that >> >> This is a perilous way to start a great topic. For certain we all want a > great language, but we would be agreeing with our own definitions of a > great language, not each-other! :) > > My definition of a systems programming language is one which > enables/allows: > > 1. ... compilation and distribution of modular binary components, which > are independently developed and updated in a backward-compatible way. This > is necessary to achieve a systems-level-ecosystem, rather than merely a > program ecosystem. Without this capability, we have a whole-program > embedded system development kit. > Agreed. And I'd note that this is where the "fragile base class" problem creates challenges for languages with inheritance. > 2. ... raw access to CPU features, hardware IO, explicit in-memory > data-layouts, and explicit memory addresses. (not only for kernel-drivers, > but also for direct access to syscall interfaces, shared memory, MMU > tables, and some types of hardware interfaces which allow user-land > preparation of commands bound for hardware) > One certainly needs these in order to write an operating system, but I think there is a limit to how much a language should do here. Syscall interfaces, for example, are traditionally done with small assembly stubs. I *do* think that the language needs to be able to express explicit memory barrier requirements. That would be a help both for kernel-type codes and for concurrent codes. > > 3. ... the capability to author software which can reach the full > potential of the hardware, without "dropping into another language". This > includes no achilles heels, such as loss of memory-layout-control, > introduction of stop-the-world-pauses, or other impediments to controlling > the final behavior and expression of the program. > The only language I know of that ultimately meets that goal is assembly language, and we *really* don't want to relegate ourselves to that. I would say rather that we want the need to drop to assembly language to be drastically minimized. For example, I really don't see a need for the programming language to have the "invalidate TLB" instruction as a primitive. That's the kind of thing for which inline or out-of-line assembly really is appropriate. > My definition of a *good* programming language is task-dependent, and is > one which: > > a. ... allows us to express a specific program we wish to express > b. ... enabling a chosen tradeoff between flexibility and safety > c. ... enabling a chosen tradeoff between coding-efficiency and readability > d. ... and which achieves our goals WRT SLA/latency and third-party > interfacing > > For me, it is (3/d) which have thus-far made garbage collection unsuitable > for systems programming. Typical garbage-collection compromises are > fantastic for *certain* applications, but I do not consider them systems > programming languages, because when (3/d) rears it's ugly-head our only > choice is to jettison the entire runtime and switch to something which > meets my definition of a systems programming language. > > Azul C4 may solve (d) but does not solve (3). > In what way does the Azul C4 collector fail to solve (3)? > On the other hand, we can count numerous user-facing systems which have > tried to more fully use GC and all had undesirable pauses which have not > been fixed to this day. > > The interactive LISP, Smalltalk, SELF environments had notorious garbage > collection pauses. > That certainly was not my experience with either LISP systems or Smalltalk systems, and I used both extensively. > I've been really excited since Azul C4 appeared to see a GUI system turn > this all on it's head. Sadly AFAIK it's not possible to implement > C4-techniques on windows, Android, or iOS... and the C4/JVM is unsuitable > for systems programming for other reasons. > I think C4 could be done on Android, which is basically built on a Linux kernel. It could be done on Windows if MSFT was sufficiently motivated. I agree that JVM is unsuited for systems programming, but I'm not sure C4 is unsuited for that. On the other hand, I think that a kernel which allocates after initialization has more design flaws than any collector can solve. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
