![]() |
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.
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.
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.
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. |
![]() |