System developers' manual

System developers' manual
SchemeStation documentation

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


Fig 1. The system architecture divided in modules

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


Development environment of the SchemeStation project: makefiles and related (final) [makefiles] [frames] [simple]
External agents (memorandum) [extagent-examples] [frames] [simple]

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 . If you plan to extend the system, we hope you to obey these rules also in order to keep the source consistent.

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

ProblemTentative solutions
I just installed the source tree and am trying to figure out what is being done in "heap.c". The point is, with my 20-year experience of writing C-programs, I haven't got a slightest clue on what's being done here. (1) Most people of the SCHEMESTATION project team do have neither.

(2) This is perfectly normal. We would have been worried if you actually had a clue.

(3) Do not change it as it might get broken.

I can't port this straightforwardly to a Windows environment. No, but you can write a SCHEMESTATION simulation in QBasic. Then you can mess around with it to an even bigger extent.