Anyone who is interested in porting this system is encouraged! We would like to know how it goes. The primary concerns when doing a port will be the size and alignment constraints of the target machine and the runtime.
The directions in this section are somewhat sparse. We tried to make the installation of SRC Modula-3 smooth, but it is another story to make the development of ports smooth. Please bear with us and tell us what we can do to improve this section.
If you want to a port to an unsupported system you should:
In the following, all the paths are relative to the directory in which you unpacked the m3.tar.gz archive.
The compiler has a small number of parameters that are used to describe the target machine. These parameters are defined in the interface m3middle/src/Target.i3 and its implementation. Edit Target.m3 to add a new machine description.
In m3build/templates create a file named new and add new to the list of known platforms in PLATFORMS. Use the other machine descriptions as a model.
Some of the Modula-3 code (and a few little pieces of C) are machine-dependent. Of course, it may be that some code we thought was machine-independent will turn out to require changes for your new architecture, so we cannot guarantee that the list below is exhaustive. In general, look at what is done for the other machines, and use the most similar one as a starting point.
In m3core/src/Csupport, add a directory new and put in it the files:
In m3core/src/C, add a directory new and put in it the files:
In m3core/src/runtime, add a directory new. Then copy one of the other platform-dependent directories into your new directory and adapt its contents to match your platform.
WARNING: ENTERING VERY OLD SECTION.put in it the files:
- m3makefile to describe the contents of the directory
- WildJmp.i3: this interface provides functions that are similar to _setjmp and _longjmp, but that do not impose any restriction on what is possible. The DS3100 version is the simplest, because on that architecture, _setjmp and _longjmp are just fine. The VAX version is the most complex, we had to rewrite our own versions because longjmp requires that the stack be popped (remember the longjmp botch message?).
In libm3/src/runtime, you can either reuse one of the StackInc-n component, or you may have to create a new one (i.e., you need a different value of n). The dependency described there is for the benefit of the garbage collector. At the beginning of a collection, the collector must find all the roots, that is, all the heap objects that are referenced from outside the heap itself. The stacks contain such pointers, and the collector scans them to find roots. However, the collector does not know the full structure of the stacks (frames, argument lists and so on); rather, it just looks at the values that are there and make conservative decisions by interpreting these values as possible pointers. For each stack, the collector initializes a pointer $P$ to the bottom of the stack; then it repeatedly tries to interpret the bits pointed by $P$ as a pointer in the heap, marks the root if the interpretation is successfull and advances $P$. The question is by how much $P$ should be advanced; if all entries in the stack are aligned at $n$-bytes boundaries, it is sufficient to increment $P$ by $n$ bytes; a smaller value would be an overkill. We have found that some machines require $n$ to be 2, and that 4 is enough for others.
LEAVING VERY OLD SECTION.
In m3core/src/float, add a directory new and copy the files that are in MODEL in that directory. The routines in these modules provide access the floating point control (to set exceptions and so on). The version in MODEL is a template, and most of the routines will fail (because of an <*ASSERT FALSE*>) if executed. The DS3100 and SPARC directories are examples of implementations for IEEE machines, the VAX directory is an example for non-IEEE machines. It is not essential that you implement the proper procedures right now: the versions in MODEL are good enough for the compiler, the driver and simple test programs. But you will have to take care of that at some point.
In libm3/src/random, you can either reuse one of the directories VAX, IEEE-le or IEEE-be, or create your own on those models. The goal is to describe enough of the floating point representation for the random number generator. There is probably some overlap with the libm3/float stuff, we will take care of that at some point.
In m3core/src/unix, you will find a bunch of interfaces to the procedures of sections 2 and 3 of U**X. Not everything is there, but we sometime dream to have a complete set; in other words, it's quite a bit of work to make sure that you have the proper descriptions, and of course, there is nothing from which these interfaces could be mechanically derived. Fortunately, the driver and the compiler rely on very few of these procedures, and any version is probably good enough for your machine. We suggest that you do the work only when you find some problems (at least, wait until you get a basic port running).
At the top level, type to the shell:
$ mkdir new-world $ cd new-world $ ln -s <wherever you unpacked m3utils/m3export> M3EXPORT <edit M3EXPORT/build-boot to point at your modified sources> $ M3EXPORT/build-boot new
After a while, you should get a compressed tar file, RELEASE/boot-new.tar.gz. Copy it to the new machine and proceed as you did for the original installation of SRC Modula-3.
Good Luck!
Last modified on Tue Mar 26 09:29:18 PST 1996 by heydon modified on Thu Jun 22 16:01:41 PDT 1995 by kalsow modified on Tue Feb 18 13:23:15 PST 1992 by mullerCopyright (C) 1992, 1996, Digital Equipment Corporation. All rights reserved.