/joh'liks/ n.,adj. 386BSD
Porting Unix to the 386: A Practical Approach



William & Lynne Jolitz

Our use of cross-tools was simply to bootstrap onto the 386 - not to perfect ongoing development. So, if we found a problem with the tool, we bypassed it with a one time workaround - cross tools didn't need to work for everything.




386BSD Cross-Tools Goals
A proper evaluation of our cross-tools was crucial to the successful generation of the earliest version of 386BSD--before the system had the ability to generate its own binaries. While everyone always wants to use the very best tools possible in all cases, we decided that what we wanted from our cross-tools was simply to be able to generate enough of an operational BSD kernel and utilities to run our language tools in a native environment. Ultimately, we want to use native tools because they are more convenient, have a shorter "compile-edit-debug" cycle, are easier to support (for example, just one architecture to worry about), and use much of the traditional program development aids provided in BSD UNIX.

In a nutshell, BSD, like most UNIX systems, expects to be developed in a native environment.

As such, our principle concern at this stage is with correctness, not optimization. Performance considerations arise only after we achieve an operational system that can be refined using traditional means. This first "bootstrap" version of utilities and kernel is compromised in areas where our cross-support mechanisms are weakest. However, if carefully selected, we can jettison these compromised areas when we "go native."

Both the kernel and early utilities are predominantly written in C, with some assembler support. Before a self-supporting kernel exists, approximately 250,000 lines of C code must be made operational via the cross-support. The chance of discovering compiler bugs, or cross-support-induced bugs, is almost certain.




<<BACK NEXT >>



Copyright 1990, 2006 TeleMuse Partners, William Jolitz and Lynne Jolitz