| # Porting Sather 1.3 |

Porting to another CPU
The description below assumes that the reader has a C library which conforms to the Gnu libraries for use in a unix-like environment. If that kind of environment is not available then it may be necessary to hand edit the compiler C source text to replace appropriate operating system service routine calls for use in the target environment. The details of this will depend on the target environment and cannot therefore sensibly be discussed in these notes.

1. The first step in porting to another CPU involves choosing a suitable location in the target file system and copying and unzipping all of the distribution files there (see also the Installation Notes for Sather 1.3). That location should be designated by the environment variable SATHER_HOME. Two other environment variables are required :-

   - LOCALE - this should have a value composed of two two-letter abbreviations separated by a Low Line character. The first two letters should be the language of the local culture using the abbreviation specified in ISO 639; the second pair defines the territory as given in ISO 3166 (see here for references). An example would be "mi_NZ" for the Maaori language in New Zealand.

     During initial beta release the only one available is 'en_NZ'!

     See also the documentation on the cultural compiler (lcc) for details of creating new cultural descriptions.

   - SATHER_ENV - this variable should be set to the value
     <SATHER_HOME>/Resources/<LOCALE>/bin/LIBCHARS

     It enables the low-level culture-dependent parameters to be read from that file which is created during cultural description compilation and moved to the appropriate directory.

2. Compile and test the garbage collector according to the instructions contained in the GC directories and make files.
3. Compile the Sather (1.2) compiler (preferably using the Gnu compiler gcc).
4. Compile the Sather (W version) compiler using the Sather compiler binary produced in the step above. The make file in SATHER_HOME should do this and the subsidiary actions needed without alteration unless the 'make' facility on the target is not Gnu make - or there is no 'make' facility (when the actions given in the make file will have to be carried out by hand!). The resulting binary should be in the <SATHER_HOME>/Bin directory.
5. If library incompatibilities exist then it will also be necessary to follow the notes in the section on porting to another Operating System which are given below.

Porting to another Operating System
The Sather Language Specification contains a section of the Required Library called Opsys. This contains the definition of those operating system environment services which are required by the Required Library. Note in particular that noimplementation classes are specified. While it is very probable that the manner of implementing the required interface specifications will be broadly similar to that for other operating systems there will be some for which the difference is quite significant (see for example the RISCOS implementation included in the distribution).

The implementer wishing to port the interface implementation should study the following notes which give the philosophy of the initial implementations which may be used as a guide.

The existing implementation design is based around the concept that there will be one top level implementation classes corresponding directly to each of the Required Library interface abstract class specifications. These classes will ensure the required semantics of the specifications.

The implementer should decide what underlying operating system services and values will be needed to provide the required functionality. Once these have been selected and their semantics checked for suitability then external OS classes should be defined for the OS interfacing specification as needed.

Depending on the gap between the semantics of the interface classes and the top level interface implementation classes it will frequently be necessary to implement the necessary semantic mapping in some one or more additional intermediary implementation classes. The facilities provided by these should then be use in implementing the top level Required Library interface classes.

The necessary semantic mapping could in principle be provided in the top level classes only. Experience has shown, however, that the run-time overhead of the interface will be less if a significant mapping is divided into two stages. The lower stage can then concentrate on providing a Sather calling interface to the OS features for use by the top level interface classes which provide the correct semantics for the implementation.

WARNING | The similarity of one operating system to another should not be relied on as a guide to successful porting. Implementations of linux/unix are notorious for having subtle differences which should be carefully checked!

Comments or enquiries should be made to Keith Hopper. Page last modified: Tuesday, 17 October 2000. |