rb@cci632.UUCP (Rex Ballard) (07/26/86)
In article <4341@decwrl.DEC.COM> williams@kirk.dec.com (John Williams 223-3402) writes: >The design process is actually both. The top and the bottom represent >the limits of the designer's knowledge, and are given a priori to the >design. The designer then works towards the middle to some form of >representative block diagram. This allows two things to happen: > >1) System functionality is defined, and a design can be evaluated >from an environmental standpoint. > >2) Primitive components are selected by virtue of their quality, choosing >the best components for the best design. > > John. I hope that people would in general agree with this, at least in theory. The problem comes when the implementation of a large system is farmed out. How should one assign the implementation? If only one person is involved, then that person can implement either way. The problem that so often occurs, is that "top level" tasks are frequently assigned to different people with "bottom level" tasks either not being considered at all, assigned to "super techies" who do not think in terms of simple interfaces, or to "junior programmers" who may not think in "general terms" about the interface. Either way, the common result is to have a large quantity of duplicate functionality. If step 2) (above) is not carefully thought out, the basic system will be more difficult to maintain. Again, when discussing "system archetecture", this can apply anywhere from the CPU design to the "User Interface" design. One of the strengths of Unix, is that "programmer friendliness" was at least as important as "user friendliness". This is a significant factor in any CPU, OS, language, or "shell". Unix may not seem user friendly today, compared to say a Mac, but compared to RT-11, it's a joy to work with. This points out the need for good "bottom up" design. If the CPU-compiler interface is relatively clean, the compiler-library is clean, the library-application programmer interface is clean, and the application-user interface is clean, the system gets good support. The same is true for CPU to peripheral interfaces. What do I mean by clean? First, the number of "mandatory arguments" should be kept to a minimum. Often, "mandatory arguments" are "hidden" in stamps that the next level must manipulate. This is a good way to get bad support at higher levels. Second, the interface should be as "simple" or "intuitive" as possible. Intel 8080 memnonics are a good example of a bad, non-intuitive interface, compared to 68K memnonics. Again, this holds true for each level. Third, "power user" interfaces should exist, but be strictly optional. For example, the IOCTL calls should be available, but the system should work with, or without them. The same goes for "timing factors" in a pipelined CPU. Fourth, the default should be either "fastest" or "smallest", with a minimum amount of effort to go from one to the other. Also "maintainable" is a useful feature. Fifth, the lowest levels should be flexible. This is a radical departure from "ROM the Bottom" approaches currently used in many systems. Often, a change at the lowest levels can be very powerful, but if the Micro-code, OS-Kernal, Drivers, or Libraries are "Set in Stone", such enhancements have to be "kludged up" at a higher level. For example, if a 4.2 application is to be run across RFS, it must be relinked, often re-compiled. One can re-compile the kernal, to make RFS work for All applications, or one could (theoreticly) "install a driver" on the running system. Ideally, the user could even "install user-specific drivers" which would effect only him, compare the "termcap" techniques of BSD to the "user-driver" of OS-9 or MS-DOS. There are several capabilities which because, as a User, I cannot "plug in", prevent one of my terminals from doing "insert line" in spite of the fact that there is a short string which could provide this functionality (hint: the terminal has "set scrolling region" and "scroll"). This becomes even more of a problem when a variety of graphics drivers are needed. There are other things that could be added to this list, but the basic idea of "planning the bottom" has been made. Rex B.