.SH Installing Little Smalltalk .PP For most users the following simple steps should suffice to build the system. .IP \(bu Unpack the sources. .IP \(bu Edit the file env.h, changing the metadefine to an already known system type. .IP \(bu Type \fImake\fP. .PP There are a few systems for which more extensive work is required; and of course porting the system to new environments may entail considerable work. The remainder of this document is intended to provide more detailed information for the curious, and to help those individuals for whom the previous instructions don't work. .SH IBM PC and Turbo C .PP For these systems there are two small changes that are required, in addition to those noted above. In the method for saveImage, class Smalltalk, file unix.c, the mode for the open statement must be 'wb', not 'w'. And in method delete, class File, file unix.c, the command used to delete files should be ``DEL'', not ``rm''. It may also be necessary to redefine the value of the global variable \fIeditor\fP (set by the script found in file script.ini, used when making the initial image). Also the name of a temporary file (found in method scratchFile, class File, file unix.st) may have to be changed. .SH Tektronix 4404 .PP There are several changes that are required to get the system to run on the 4404. Start by defining the metadefine constant SYSV in env.h. Next, change the Makefile in the following ways, .IP \(bu Translate all the .o extensions to .r . .IP \(bu Remove any CFLAGS definitions. .IP \(bu Change the rules for parse and st to use +o= notation, which must appear at the end. Also add a call on headset, setting the program size to at least 512K (more if you have it). .DS I st: \fIfile names\fP cc \fIfile names\fP +o=st headset st +b=512K .DE .SH Porting to new systems .PP There are many ways in which compilers and operating systems differ from each other. A fair amount of work has been expanded in making sure the software will operate on most machines, which requires that different code fragements be used on different systems. In large part these are controlled by a single ``meta-define'' in the file env.h. Setting this one value then causes the expansion of another code segment, which then defines many more options. .PP In the event that you are attempting to port the software to a system that has not previously been defined, you will need to decide which set of options to enable. The next two sections contain information you may need in making this determination. .SH Define Options .PP Many options are specified merely by giving or not giving a DEFINE statement in the file env.h. The following table presents the meaning for each of these values: .de Op .IP \\fB\\$1\\fP .br .. .Op ALLOC Defined If there is an include file called alloc.h which defines calloc, malloc, and the like. .Op BINREADWRITE Defined if the fopen specification for binary files must include the "b" modifier. This is true on many MS-DOS inspired systems. .Op NOENUMS Defined if enumerated datatypes are not supported. If defined, these will be replaced by #define constants. .Op NOTYPEDEF Defined if the typedef construct is not supported. If defined, these will be replaced by #define constructs. .Op NOVOID Defined if the void keyword is not recognized. If defined, expect \fIlint\fP to complain a lot about functions returning values which are sometimes (or always) ignored. .Op SIGNALS Used if \fIboth\fP the package and the package are avilable, and if the routine used to set signals is signal. Incompatible with \fBSSIGNALS\fP. .Op SSIGNALS Used if \fIboth\fP the package and the package are available, and if the routine used to set signals is ssignal. Incompatible with \fBSIGNALS\fP. .Op STRING Used if the string functions (strcpy, strcat and the like) are found in . This switch is incompatible with \fBSTRINGS\fP. .Op STRINGS Used if the string functions (strcpy, strcat and the like) are found in . This switch is incompatible with \fBSTRING\fP. .LP In addition, several routines can optionally be replaced by macros for greater efficiency. See the file memory.h for more information. .SH Object Memory .PP There are several datatypes, not directly supported by C, that are used in the Little Smalltalk system. The first of these is the datatype byte. A byte is an eight bit unsigned (hence positive) quantity. On many systems the appropriate datatype is unsigned char, however on other systems this declaration is not recognized and other forms may be required. To aid in coverting to and from bytes the macro byteToInt() is used, which converts a byte value into an integer. In addition, the routines byteAt and byteAtPut are used to get and put bytes from byte strings. .PP The other datatype is that used to represent object points. On most machines in which a short is 16 bits, the datatype short should suffice. Much more information on the memory module can be found in the file memory.h. .SH Options in Building the System .PP To create the parser type .DS I make parse .DE .PP The resulting program, called parse, is used to generate the object image initially loaded into the bytecode interpreter. .PP Next, make the interpreter itself by typing .DS I make st .DE .PP Note that the interpreter and the parser share some files. .PP Finally, produce an initial object image. The image created when you type .DS I make sunix .DE .LP is the smallest and fastest. It is a single process version of smalltalk. A slower multiprocess version can be created by typing ``make munix''*. .FS * Multi processing from munix is done entirely in Smalltalk. While this is a good idea from the point of view of keeping the bytecode interpreter small and giving one the greatest flexibility, there seems to be a dramatic performance penalty. I'm considering the alternatives. .FE Of more interest, an image containing test cases can be generated by typing ``make stest''. This command compiles several test cases, then runs st on a script which invokes all the test cases. There is a similar command mtest for the multiprocessing version. .PP Once you have created an object image, type .DS I st .DE .LP to run the system. By default the image file ``imageFile'' is read. You can optionally use a different image file by giving the name on the command line following the st command. .SH Compiler Bogosities .PP This section will detail some of the unnatural actions you may have to perform to get Little Smalltalk to work with a few brain damaged compilers. Since there are so few of these, it I see it as a problem more with the compilers than with the system, the code make no accomodation for these. .PP On some older Sequent Balance C compilers, incorrect code is produced for .DS I hash %= (objectSize(symbols) / 2) .DE .LP In the file image.c. This should be replaced by .DS I hash = hash % (objectSize(symbols) / 2) .DE .PP On many systems external names are restricted to six (or even five!) characters. This causes significant problems. I have heard of systems which automatically generate a sed script to take care of this, but have not found one yet. If you know of such a thing let me know. .SH Helping Others .PP If you succeed in getting Little Smalltalk ported to a machine or operating system not described in env.h, I would be most pleased to get a listing of the changes you made. These can then be incorporated into the latest distribution.