/joh'liks/ n.,adj. 386BSD
The tool chest for 386BSD cross support included compiler, assembler, loader, libraries and include files. It did not include an emulation environment.
|
The C Compiler: The bulk of our effort is organized around the C compiler. For the 386BSD project, we relied upon the Free Software Foundation's (FSF) GCC compiler, version 1.34. At the beginning of this port, we had little familiarity with the strengths and weaknesses of GCC. We were also uncertain about its usefulness as an operating systems development tool, as it appeared primarily alongside other 386 C compilers on extant System 5 UNIX systems. Unfortunately, we cannot supply written code fragment examples from GCC (or any other FSF software) in this article due to constraints of the "copyleft" (see the accompanying article "Copyrights, Copylefts, and Competitive Advantage"). 386 Protected-mode Assembler: The remaining 386 code, particularly the code used for interfacing to non-C mechanisms and data structures needed to support i386 and ISA hardware functionality, was written in assembly language. The FSF's GAS assembler was used for this purpose, more out of need than preference. The great majority of problems we encountered with the port were traced to "hidden surprises" and "features" in GAS, which we bypassed with clever use of inline code and other contrivances. GAS is functional and proven, if not pretty. Linker-Loader: Object modules created by GAS were linked together by an object module linkage editor. We had a wide variety of candidates available from BSD, FSF, and others from which to choose. However, because the object file format exactly matched the arrangement of our cross-host (a National Series 32000 machine), we put off the ultimate decision by using our cross-host's native UNIX ld command. This worked without modification to our satisfaction. Communications and File Transfer: We needed a way to get programs and files created on our cross-host transferred to our 386 PC. Many cross-host to PC communications programs are available, and we settled on Kermit and NCSA Telnet (ftp) to do the job. Protected-mode Loader: Once we had transferred the programs to the PC, we used our protected-mode loader program (see "Three Initial PC Utilities" in DDJ, February 1991 ) to load the programs and execute them in 386 protected mode. Ancillary Tools: In addition to the heavy hitters, various minor commands are also needed to create and organize the object libraries. Commands such as ar, ranlib, nm, and lorder were required. Again, like the ld command above, we were able to use the cross-host's native commands due to the identical executable format and byte order of cross-host and our 386. In addition to these programs, our cross-support facility must have the following data objects present to build kernel and utilities: Object Libraries: The standalone system (libsa.a) and utilities (libc.a and others) make great use of their respective library calls. These libraries satisfy, on the average, a few hundred of the function entry and data structure references invoked by various BSD utility programs. Most of the machine-dependent portions of BSD utilities are located in the libraries, so the majority of effort expended in porting the utilities is focused on the libraries. Over the course of the 386BSD project, we wrote the machine-dependent code into the libraries to get a given utility operational only as needed, rather than writing it all at once. Incremental coding provided a tactical advantage, because by the time we needed to wrestle with the most difficult code, we had quite a bit of seasoned experience with the 386. Include Files: In addition to object libraries, we must provide a complete set of include files for use with our cross-support package. A simple approach might be to have all references to include files directed to a separate i386 include directory, but this would interfere with the pathnames invoked by a variety of makefiles and shell scripts, not to mention all the embedded references in the source code itself. After finding over a hundred references to absolute pathnames, with no end in sight, we gave up on this approach and did the unspeakable--put into place on the cross-host all 386 include files. By virtue of the shell commands to386 and back2normal, we could switch our cross-host back and forth in this manner. Thank goodness, no other users needed to compile native programs at the time; they would have been somewhat surprised! For we did not include any kind of emulation of runtime environment - so, if for example in building a program, if it ran a program to create code to then compile - like building a table, then the table was built for the cross development host, the build stopped, the table manually editted, and the build restarted.
|
|