mce@tc.fluke.COM (Brian McElhinney) (12/02/88)
In article <390@cvbnet2.UUCP> pcolby@robbie.UUCP (Peter Colby) writes: > 1) OS 360 was written in assembly language. Even today there are not a > whole lot of programs equivalent in either size or complexity. > Remember, we're talking somewhere around 1965-1968. Read > "The Mythical Man Month" by ?? Brooks. The issue isn't complexity, > it's lines of code. You read a different "Mythical Man Month" than I. The issue was the complexity of: * Understanding what they were supposed to be producing. * Understanding how they should go about designing it. * Understanding how they go about implementing that design. One *part* of the solution to the implentation is HOLs. There are presently many, many, systems with more complexity that OS 360 -- they are just organized in a manner that reduces the complexity of individual parts to something that is more understandable. OS theory, compiler theory, software engineering practices were all in their infancies when Brooks managed the OS 360 project. See Brooks' more recent paper "No More Silver Bullets" (IEEE Computer in 1987). > The only reason HOLs are considered an advantage is because most > programmers are really coders Assembly language is inherently more complex, leading to less real work done, and more time wasted on complexities that are not a part of the real problem (the real problem is getting the job done, correctly, not organizing register usage for every line of code you write, etc.). Thus HOLs are an advantage because they help reduce complexity. The lines-of-code stat is a side effect (and should be taken with a grain of salt, as should any software metric). > Automate coding from design specs and you lose all advantage of > HOLs. There is a great deal of difference between specifications and a design that implements them. Because of this, automated coding for specifications is, in Brooks' words, a "silver bullet"; a potential part of any real gain in productivity, but not a general answer in and of itself. Since it is only a partial solution, the need for HOLs remains (and indeed, given the difficulty of creating such a program, it would likely be a lot more efficient *in development time* to have the automated code generator emit HOL). > 2) One of the major savings in using assembly language IS due to > "tricks of the chip". I remember doing assembly programming on a CDC > 6600 (1975). Two techniques in particular were used to speed up > programs; First, we coded inner loops to keep the entire intruction > stream in the instruction cache - no memory access (for > instructions) - major gain; second, we interleaved instructions to > take advantage of mutually independant asynchronous functional units > - the units only synchronized to access common registers - depending > upon the task, this could gain little to a lot. But this is 1988. You are simple describing what people are doing with with modern compilers (MIPS is a good example). And what others are doing inside the CPU (the 80960 transparently does the interleave you describe; SPARC *requires* the compiler to do be doing it). > 3) The other major saving in using assembly language is "optimization". > Yes, having to include support code and other general library > routines from the compiler cuts down on code efficiency, but the > major problem is that most commercial compilers generate horrible > code. Hand coding in assembly makes up for the stupidity of > compilers. Of course, good compilers can be written but I suspect > that the R&D effort involved would push the potential selling price > out of the reach of most buyers. However, take a look at the IBM > FORTRAN H (optimizing) compiler or the original PASCAL compiler > written specifically for the CDC 6600. By this same logic, we should all be riding horses. Yes, poor compilers have been written. But just as cars improved, so will compilers. The need for extensive R&D decreases as the knowledge base increases, so you can expect compilers to get better. Look at the GNU C compiler. It's a very good compiler, yet it is free. Also FORTRAN H and the original PASCAL are very different from "modern" HOLs, which solve very different, much more difficult problems. > 4) It's still a truism that appropriate algorithms buy you far more > than hand optimization. However, once you have a working program you > can substantially improve it's speed by analyzing the bottlenecks > and recoding the critical procedures (or loops) in assembly > language. As I said, assemble language is useful in its place. This, and a very few others, are the useful places. Assembly language will never disappear, but it has already faded away considerably, and will continue to do so. Brian McElhinney mce@tc.fluke.com