한국   대만   중국   일본 
Constellation
The Wayback Machine - https://web.archive.org/web/20030808161927/http://www.humbug.demon.co.uk:80/dave/constellation/constellation.html

Constellation

Questions And Answers

I thought about how to write some comments on my current project, Constellation, and decided that FAQ-style questions and answers might explain things best. If you have any comments or questions about what I mention below please feel free to drop me a line (flames to /dev/null).

What is Constellation?

Constellation is the name I've given to my latest systems research project and builds upon many of the ideas I've encountered and/or developed in other operating systems, applications and programming languages. The aim of the project is to evolve a complete software system from the lowest level assembly code through progressively more complex stages to a fully functioning distributed system.

Why do a new development?

I used to believe that most of what I wanted from computers could be solved simply by providing better operating systems - experience has taught me otherwise. The problem is the complexity of implementing and debugging concurrent software, in parallel with library code, device drivers, test suites, etc, etc, with languages that aren't helpful to the process.

A good example of where language support is just not up to the task is shown by some of the development work I undertook with Artemis: One of the fundamental design decisions was to separate specific services out into individual modules and to then separate these modules with virtual memory management hardware because my programming language, C, was not safe. As these server modules became progressively more specialised, I found that much of what I had originally envisaged would be implemented within library code could be more elegantly implemented within separate services. Unfortunately the costs associated with memory protection made the cost of inter-service transactions unacceptably high.

Clearly there are much safer languages available that would allow me to implement my modular approach without using VM hardware support, but unfortunately the cost associated with these languages is a loss of efficiency. With something like Oberon-2 this is a small loss, but nontheless it is present.

At about the same time I was considering ways around my Artemis VM problems I started to feel that perhaps a well defined hierarchy of languages might present a better way to develop systems than attempting to use a single language. I have decided to try an approach of defining each successive language in terms of the next lower-level one such that I could perform a relatively simple source-source rewrite operation to "compile" code written in it. This may well lead to far slower compilation, but the individual parts will be far more comprehensible. In addition this approach seems somewhat natural as this is remarkably similar to the way in which my layering of system services worked within Artemis (kernel, device drivers, file systems and applications, each relying upon the layer below). I hope that the ability to access many levels of language will allow me to use "purer" higher level languages or to simplify the task of developing a new higher level language.

What are the target platforms?

I've decided to try and support development for platforms as small as 8 bit microcontrollers, through to 64 bit and beyond (when they become available). I have been convinced for some time that the embedded systems present a far more interesting environment in which to work than many more conventional computing environments. Generally new operating systems have been designed for either small real-time applications or more general computing, butI do not subscribe to the view that these absolutely need different solutions.

This doesn't mean that I expect to do the same things with a 12MHz 8051 microcontroller and 32kbytes of RAM as with dual 150MHz Pentiums and 256 MBytes of RAM, but at the lowest levels I see no reason why there shouldn't be a similarity in approach. Having developed large amounts of assembler and C code for both types of system I find there to be more similar features than dissimilar ones! It suspect that many Forth users would arrive at a similar conclusion.

As an initial test environment I plan to develop code for 386, 8051 and PowerPC processors as this should provide a good mix of target technologies. Assuming that I can get access to suitable hardware I would also like to support SMP operations.

When will it be available to use/develop/look at?

I think it would be safe to call it Constellation '98 for now :-) Based on my experiences of developing Artemis and previously working with VSTa I don't expect any quick results. I'll obviously have some things running before that, but I'm not sure that I want to release anything until I've got several layers of software working. Even with this timescale (of about 2 years) I don't expect to see anything that's very optimised until later - I may surprise myself, but I'm not planning to just yet!

Back to Dave's home page

Last Updated: 25th September 1996 DJH