System developers' manual
Document formatted by vherva at Fri Apr 24 11:23:35 1998 on the host schemestation. This document is produced by the SchemeStation project during the Tik-76.115 course.
| |||||||
1 Introduction | |||||||
This part of the manual is aimed for those willing to mess with the sources and to develop the SCHEMESTATION system further. We give an insight to the existing documentation of the implementation and specification and describe the coding and commenting disciplines used.
| |||||||
2 Module division | |||||||
SchemeStation is written in both C and scheme. The source code is divided in several modules, each of which implements a separate task. Throughout the project we have tried to comment the code and adhere to strict disciplines when it comes to documentating both the design and implementation issues. Because of this, we can now provide a hopefully fairly detailed description on the implemention of each module. (For the module quantisation of SchemeStation, please refer to SchemeStation Technical Specification.) Also, there is a separate document for each module, that detailedly specifies what each module should do. The aim has been that based on a specification document a module could be rewritten without seeing the original module, so that it still works with rest of the system.
| |||||||
2.1 Core parts written in C | |||||||
In the simulator-like implementation of a SchemeStation Operating System [See Operating system specification] the parts that simulate hardware are written in C. These include the virtual machine and, in a way, the heap. Also, the networking simulation along with the messaging system simulates not only the computer hardware, but a whole network of computers and networking equipment.
There are also several core modules implemented in C:
| |||||||
2.2 Parts written in Scheme | |||||||
Some fundamental parts of the system are written in Scheme, also. The most promiment are:
In addition to the in-core modules listed above (compiler and assembler may not be concidered as in-core modules, but they are fundamental, anyway) the distribution includes certain interfaces and additional programs. These include:
| |||||||
3 The source tree | |||||||
The full source tree of the project is included in the distribution. A detailed explanation of the contents of the tree is found from Administrators manual.
| |||||||
4 Architecture documentation | |||||||
| |||||||
4.1 Implementation Documents | |||||||
Addressing module implementation (final) [addressing-implementation] [frames] [simple] External Agent Interface Implementation (final) [extagent-implementation] [frames] [simple] Messaging System Implementation (final) [messaging-implementation] [frames] [simple] Networking Implementation (final) [network-implementation] [frames] [simple] | |||||||
4.2 Technical Specifications | |||||||
Addressing module specification (final) [addressing-specification] [frames] [simple] Compiler technical specification (memorandum) [compiler-spec] [frames] [simple] External Agent Interface Specification (final) [extagent-specification] [frames] [simple] Heap Module Specification (memorandum) [heap-specification] [frames] [simple] Heap layout (draft) [heap-layout] [frames] [simple] Messaging System Specification (final) [messaging-specification] [frames] [simple] Networking Specification (final) [network-specification] [frames] [simple] Scheduler definition (preliminary-draft) [scheduler] [frames] [simple] Standard protocols (memorandum) [protocols] [frames] [simple] Virtual machine definition (final) [ssvirtual] [frames] [simple] Virtual machine layout and interface definition (final) [vm-layout] [frames] [simple]
| |||||||
5 Coding discipline | |||||||
Throughout the project we obeyed a coding disclipline defined in Project coding policy. With this, we hoped to reach several goals. The coding style was aimed to be be consistent throughout the project. The author of a piece of code should not be able to be deduced on the basis of the style of the piece only. The code should be as self-explanatory as possible. Internal integrity tests in form of checked pre- and post-conditions and other similar mechanisms should have been used in order to spot possible faults in the software as early as possible. Code should documented. This was aided by a separate utility, that extracts the description of the functions and data structures from the code. The structure of the code should now be modular and easily understood.
The exact directive on writing code can be found in
| |||||||
6 Submitting additional code to the official distribution | |||||||
You should email us (schemestation@schemestation.cs.hut.fi) the diff file between the original sources and the ones that you've pathced. Use the unix diff utility for this. We maintain the right to inspect, change and possibly even abandon the changes you've made before merging them into the distribution.
| |||||||
7 Troubleshooting | |||||||
|
© SchemeStation project 1997-1998 | [Back to the document index] |