The COSA Development Plan |
||
|
|
Objective
ObjectiveThe ultimate goal of the COSA project is to build a general purpose operating system and a suite of visual software construction tools based on the COSA programming model. The first phase of the plan is to create tools and components for existing operating systems such as Linux, Windows, Mac, etc... This is meant to bring most of the reliability and productivity benefits of COSA to legacy systems as fast as possible. Later, after enough tools and components have been deployed to the point where the model is considered stable, we can tackle the task of putting together a full-blown COSA operating system. Most of the components and applications created during the first phase of the project, including the development tools, will be migrated over to the new system. Hopefully, by that time, we will be able to interest chip manufacturers to design a COSA optimized CPU. This page is a first draft description of the various phases of the plan.
The COSA Virtual MachineThe COSA Virtual Machine (CVM) is an interpretive execution kernel that runs non-compiled COSA applications created with the COSA Design Studio. Using a CVM has several advantages:
The disadvantage of using a CVM is slower performance due to its interpretive nature. Note, however, that the CVM does not interpret ASCII text à la BASIC. COSA objects (cells) are binary data structures with predefined cell types and addressing modes. The CVM contains highly optimized code for each type of cell and each addressing mode. This makes COSA applications running under the CVM almost as fast as compiled applications. The current plan calls for implementing the CVM in C/C++ and/or assembly language.
The COSA Design StudioThe COSA Design Studio (CDS) is a graphical software development environment which is hosted on one or more existing operating systems. Its purpose is to facilitate the construction of COSA components and applications. Initially it will be written in a traditional high level language such as C++. Once the system is stabilized, it will be rewritten using COSA components exclusively. The studio has several important features as follows:
The COSA CompilerThe COSA compiler is used to generate fast, optimized, standalone COSA executables. Standalone means that each application has its own internal execution kernel. This will make the COSA model immediately applicable to real-time embedded environments or any application where high performance is essential. The compiler will simply translate a COSA component created with the COSA design studio into C code. The C code can then be compiled by an existing C compiler into a native code executable. Although the compiler is a standalone executable, it can be invoked directly from a menu item in the design studio.
The COSA Operating SystemThe COSA operating system is a general purpose, high-dependability, network operating system. It is designed to run only COSA applications and components created with the COSA design studio. The rationale for building a pure COSA system is that every part of the system is guaranteed to obey COSA's strict programming principles. The OS consists of an execution kernel and various service components and applications such as the COSA Design Studio and internet browser. The plan calls for having the OS use an external database via network access components, at least until a pure COSA-hosted database can be developed. The execution kernel works essentially like the COSA virtual machine described above. The main difference is that no special code is needed for interfacing with legacy systems. In addition, the component manager translates effector cells into native processor code snippets immediately on connection. This way the kernel can execute the code directly as opposed to interpreting it. One of the things that differentiate the COSA operating system from most other systems is that COSA is not a monolithic and/or layered system. COSA is a virtual environment for virtual interacting objects. A COSA application is considered to be no different than a COSA service component such as the file I/O component or the print manager. So, in a sense, any application is an extension of the operating system.
The COSA DatabaseInitially there will be no resident database in the COSA operating system. The COSA design studio will access an existing database via the network, using a network component. My current philosophy is that the traditional file system leaves a lot to be desired. I believe everything should be stored in a database. A COSA component--a collection of linked data structures--is ideally suited for database storage. There is no reason to reinvent the entire wheel, however. Existing SQL and object databases work fine. It should be possible to adopt the storage structure of an existing database and create a pure COSA interface and management components for it. This way, the system can maintain data and protocol compatibility with legacy systems.
To be continued...
Next: CVM Design Document
Microsoft® and Windows® are registered trademarks of Microsoft Corporation.
Send all comments to: louis.savain@sbcglobal.net ©2002 Louis Savain |