Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!bloom-beacon!CALSTATE.BITNET!PAAAAAR From: PAAAAAR@CALSTATE.BITNET Newsgroups: comp.software-eng Subject: Re: optimizing compiler technology ==> help for SE? Message-ID: <8911122359.AA00311@mwunix.mitre.org> Date: 12 Nov 89 23:57:46 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 162 In Software Engineering Digest v6n78 "Paul C. Clements" notes that many sample arguments for using HLL, modularization, and other SE techniques are invalid in his environment. Performance requirements sometimes dominate requirements for clarity, reusability, economy, amendabillity, testabillity, elegance, managability,... SE has recently been aimed at these qualities almost to the exclusion of . Let me argue that SE plus compilers is doomed to fail: (1) Typical manufacturers' compilers produce Inefficient code. Hardware manufacturers have to design operating systems and compilers to be inefficient because this increases the demand for the more expensive pieces of hardware, and so increases profit s. Further adding optimization costs time and money and increases production cos ts. It is the task of a company to maximize profits... Conclusion - Efficient software is DIY or from a software company. (2) Optimisation is worse than NP complete. Its not computable! Predicting the run time of any given program on any given piece of data is a well known unsolvable problem. If such a program exists then there will exist a program and some data for which it will fail to predict the correct time. Hence there is no program that guarantees optimal code... (3) Structure and efficiency. In the Journal of the ACM some years ago some theorists proved that eliminating GOTOs from some programs lead to an exponential growth in program text or in run time. I've never met a real program with this property:-) Solution :- KISS! (1) Distinguish design from code. A blueprint is not the object! (2) Use a simple blueprint notation that is one-one with assembler. (3) Develop tools to edit and assemble the notation. Sub-Problem In software engineering we don't have a good popular design notation. (Not just *my* opinion - Hoare, Sutherland, and others have said the same thing) However there do exist some working notations: Tripp LL "A survey of Graphical Noations for Program Design - An Update Software Engineering Notes Vol 13 No 4 pages 39-44 (Oct 1988) Jonsson, Dan, "Graphical Program Notations: On Tripp's Survey, the Past, and the Future", Software Engineering Notes Vol 14 No 5 pages 78-79 (July 1989) Example 1 Rob Witty invented Dimensional Flowcharts some years ago to allow him to produce efficient and yet well designed software. They are easy to draw and edit. There is a minimum of decorative graphics. They are designed for stepwise refinement/modular code. They work with data directed methods as well. Program structure and the diagram layout correspond one-one. There is a simple way to map a Dimensional Chart into ASCII/EBCDIC... Simple algorithms exist that (1) assemble the coded charts into efficient machine code (2) print, plot or display coded charts. The tools were on a specialised machine in the Rutherford Computer Labs in the UK and before there was a mass market for software. I don't think it is available for any modern machines... The rules are: 1. No BOXES. 2. Sequences are Vertically down the page. Sequence \ A : B : # 3. When there are several alternative branches they are spread out horizontally across the page with a line across the top. IF \_____________________ : : (condition for A (condition for B : : A B : : # # 4a. If a sequence can repeat (a loop) then it terminates with a star 4b. Otherwise a sequence terminates with a hash sign (drawn, plotted and displayed as the electrical engineers symbol for 'earth ') 5. A loop can have several EXIT points (marked with a 'C' shape for Condition). LOOP \ : ( WHILE A is next : Do something to A : * 6. A diagonal line indicates refinements/macro definitions/subprograms and connects the high level description (down and left) to the detailed form. 7. A "Devil's Tail" indicates a GOTO (just in case...). References Botting, Dick, "Comments on Tripp's Graphical Notations" Software Engineering Notes Vol 14, No. 1 p83 (Jan 1989) Witty RW "Dimensional Flowcharting" Report RL-76-132/A, Ruhterford Labs, Chilton, England, 1976 I can EMAil samples if you wish. Example 2. System Software for MU5 (Anecdote) The 5th machine designed at Manchester University, England, had software produced by two distinct teams of experts - the designers and the coders. The designers drew and editted flow charts. The coders used natural intelligence to convert the charts into code. Design changes were made by the designers and implemented by coders. The designers worked on paper, the coders worked with the code. A program printed out the updated flow chart, from the code. The coders ran the tests as well... Has anyone got any info on whether how this worked out in the long run... Example 3. Use the Brackets(S) program on a cheap PC to do the design in Warnier/Orr notation. There exist simple algorithms for converting Warnier's noation into efficient code. (Warning - I am convinced that the coding used in the text books tends to generate buggy loops....) KISS technology like the above can get the benefits of visible design, for a small investment in technology, and no loss of performance. ------------------------------------------------------------- Richard J. Botting, Department of computer science, California State University, San Bernardino, 5500 State University Parkway, San Bernardino CA 92407 PAAAAAR@CCS.CSUSCC.CALSTATE paaaaar@calstate.bitnet PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU ---------------------------------------------------------- What this country needs is a good $5M Ada Compiler! ----------------------------------------------------------