FORTRAN Now: FORTRAN the First Generation Backus at IBM Backus
Total Page：16
File Type：pdf, Size：1020Kb
9/23/20 Highlights of Psuedo-Code • Virtual computer – More regularity FORTRAN – Higher level • Decreased chance of errors – Automate tedious and error-prone tasks • Increased security CS4100 – Error checking Dr. Martin • Simplify debugging – trace From Principles of Programming Languages: Design, Evaluation, and Implementation (Third Edition), by Bruce J. MacLennan, Chapter 2, and based on slides by Istvan Jonyer. 1 2 Now: FORTRAN Backus at IBM The First Generation • Visionary at IBM • Early 1950s • Recognized need for faster coding practice – Simple assemblers and libraries of • Need “language” that allows decreasing costs to subroutines were tools of the day linear, in size of the program – Automatic programming was considered • Speedcoding for IBM 701 – Language based on mathematical notation unfeasible – Interpreter to simulate floating point arithmetic – Good coders liked being masters of the trade • Laning and Zierler at MIT in 1952 – Algebraic language 3 4 Backus at IBM Meanwhile • Goals • Grace Hopper organizes Symposia via Office of Naval Research (ONR) – Get floating point operations into hardware: IBM 704 • Exposes deficiencies in pseudo-code • Backus meets Laning and Zierler – Decrease programming costs • Later (1978) Backus says: • Programmers to write in conventional mathematical notation – “As far as we were aware we simply made up the language as we went along. We did not regard language design as a difficult • Still generate efficient code problem, merely as a simple prelude to the real problem: designing • IBM authorizes project a compiler which could produce efficient programs.” – Backus begins outlining FORTRAN • FORTRAN compiler works! • IBM Mathematical FORmula TRANslating System – Has few assistants – Project is overlooked (greeted with indifference and skepticism according to Dijkstra) 5 6 1 9/23/20 FORTRAN timeline FORTRAN • 1954: Project approved • 1957: FORTRAN – First version released • Goals • 1958: FORTRAN II and III – Decrease programming costs (to IBM) – Still many dependencies on IBM 704 – Efficiency • 1962: FORTRAN IV – “ANS FORTRAN” by American National Standards Institute – Breaks machine dependence – Few implementations follow the specifications • We’ll look at 1966 ANS FORTRAN 7 8 Sample FORTRAN program Structural Organization DIMENSION DTA(900) • Preliminary specification did not include subprograms SUM 0.0 (like in pseudo-code) READ 10, N • FORTRAN I, however, already included subprograms 10 FORMAT(I3) DO 20 I = 1, N READ 30, DTA(I) Main program 30 FORMAT(F10.6) IF (DTA(I)) 25, 20, 20 Subprogram 1 25 DTA(I) = -DTA(I) . 20 CONTINUE . … . Subprogram n 9 10 Constructs Declarative Constructs • Declarative constructs • Declarations include – (First part in pseudo-code: data – Allocate area of memory of a specified size initialization) – Attach symbolic name to that area of memory – Declare facts about the program, to be – Initialize the memory used at compile-time • FORTRAN example • Imperative constructs – DIMENSION DTA (900) – (Second part in pseudo-code: program) – DATA DTA, SUM / 900*0.0, 0.0 • initializes DTA to 900 zeroes – Commands to be executed during run-time • SUM to 0.0 11 12 2 9/23/20 Imperative Constructs Building a FORTRAN Program • Categories: • Interpretation unacceptable, since the selling point – Computational is speed • E.g.: Assignment, Arithmetic operations • Need the following stages to build: • FORTRAN: AVG = SUM / FLOAT(N) – Control-flow 1. Compilation Translate code to relocatable object code • E.g.: comparisons, loop • FORTRAN: 2. Linking – IF-statements Incorporating libraries (resolving external dependencies) – DO loop 3. Loading – GOTO Program loaded into memory; converted from relocatable to – Input/output absolute format • E.g.: read, print 4. Execution • FORTRAN: Elaborate array of I/O instructions (tapes, drums, Control is turned over to the processor etc.) 13 14 DESIGN: Control Structures Compilation • Compilation has 3 phases – Syntactic analysis • Control structures control flow in the • Classify statements, constructs and extract their parts program – Optimization • FORTRAN has considerable optimizations, since that was the • Most important statement in FORTRAN: selling point – Assignment Statement – Code synthesis • Put together parts of object code instructions in relocatable format 15 16 DESIGN: Control Structures Arithmetic IF-statement • Machine Dependence (1st generation) • In FORTRAN, these were based on • Example of machine dependence native IBM 704 branch instructions – IF (a) n1, n2, n3 – Evaluate a: branch to – “Assembly language for IBM 704” • n1: if -, • n2: if 0, FORTRAN II statement IBM 704 branch operation • n3: if + GOTO n TRA k (transfer direct) – CAS instruction in IBM 704 GOTO n, (n1, n2,…,nm) TRA i (transfer indirect) GOTO (n1, n2,…,nm), n TRA i,k (transfer indexed) • More conventional IF-statement was later IF (a) n1, n2, n3 CAS k introduced IF ACCUMULATOR OVERFLOW n1, n2 TOV k – IF (X .EQ. A(I)) K = I - 1 … … 17 18 3 9/23/20 Principles of Programming GOTO • The Portability Principle • Workhorse of control flow in FORTRAN – Avoid features or facilities that are • 2-way branch: dependent on a particular computer or a IF (condition) GOTO 100 case for false small class of computers. GOTO 200 100 case for true 200 • Equivalent to if-then-else in newer languages 19 20 n-way Branching Reversing TRUE and FALSE with Computed GOTO GOTO (L1, L2, L3, L4 ), I 10 case 1 GOTO 100 • To get if-then-else –style if: 20 case 2 GOTO 100 IF (.NOT. (condition)) GOTO 100 30 case 3 case for true GOTO 100 40 case 4 GOTO 200 GOTO 100 100 100 case for false • Transfer control to label Lk if I contains k 200 • Jump Table 21 22 n-way Branching Loops with Computed GOTO • Loops are implemented using combinations GOTO (10, 20, 30, 40 ), I of IF and GOTOs 10 case 1 • Trailing-decision loop: GOTO 100 … … 20 case 2 100 body of loop GOTO 100 IF (loop not done) GOTO 100 30 case 3 • Leading-decision loop: GOTO 100 100 IF (loop done) GOTO 200 40 case 4 GOTO 100 …body of loop… 100 GOTO 100 • IF and GOTO are selection statements 200 … • Readable? 23 24 4 9/23/20 But wait, there’s more! Hmmm… • Mid-decision loop: • Very difficult to know what control 100 …first half of loop… structure is intended IF (loop done) GOTO 200 …second half of loop… • Spaghetti code GOTO 100 • Very powerful 200 … • Must be a principle in here somewhere 25 26 Principles of Programming GOTO: A Two-Edged Sword • The Structure Principle (Dijkstra) • Very powerful – The static structure of the program should – Can be used for good or for evil correspond in a simple way to the dynamic • But seriously is GOTO good or bad? structure of the corresponding computations. – Good: very flexible, can implement elaborate control structures • What does this mean? – Bad: hard to know what is intended – Should be able to visualize behavior of – Violates the structure principle program based on written form 27 28 Ex: Computed and Assigned But that’s not all! GOTOs • We just saw the Computed GOTO: GOTO (L1, L2, …, Ln), I – Jumps to label 1, 2, … ASSIGN 20 TO N • N has address of stmt • Now consider the Assigned GOTO: 20, say it is 347 GOTO N, (L1, L2, …, Ln) – Jumps to ADDRESS in N • Look for 347 in jump – List of labels not necessary GOTO (20, 30, 40, 50), N table - out of range – Must be used with ASSIGN-statement • Not checked ASSIGN 20 TO N • Fetch value at 347 and use as destination for – Put address of statement 20 into N jump – Not the same as N = 20 !!!! • Problem??? – Computed should have been Assigned 29 30 5 9/23/20 Ex: Computed and Assigned Principles of Programming GOTOs • The Syntactic Consistency Principle I = 3 • I expected to have an address – Things that look similar should be similar and things that look different should be • GOTO statement with different. GOTO I, (20, 30, 40, 50) address 3 – Probably in area used by system, i.e. not a stmt • Problem??? – Assigned should have been computed 31 32 Syntactic Consistency Even worse… • Best to avoid syntactic forms that can be converted to • Confusing the two GOTOs will not be other forms by a simple error – ** and * caught by the compiler – Weak Typing (more on this later) • Violates the defense in depth principle • Integer variables – Integers – Addresses of statements – Character strings • Maybe a LABEL type? – Catch errors at compile time 33 34 Principles of Programming The DO-loop • Fortunately, FORTRAN provides the DO-loop • The Defense in Depth Principle • Higher-level than IF-GOTO-style control structures – No direct machine-equivalency – If an error gets through one line of defense, DO 100 I = 1, N then it should be caught by the next line of A(I) = A(I) * 2 defense. 100 CONTINUE • I is called the controlled variable • CONTINUE must have matching label • DO allows stating what we want: higher level – Only built-in higher level structure 35 36 6 9/23/20 Nesting Principles of Programming • The DO-loop can be nested • Preservation of Information Principle DO 100 I = 1, N – The language should allow the representation of ... information that the user might know and that the DO 200 J = 1, N compiler might need. ... 200 CONTINUE • Do-loop makes explicit 100 CONTINUE – Control variable – They must be correctly nested – Initial and final values – Optimized: controlled variable can be stored in – Extent of loop index register • If and GOTO – Note: we could have done this with GOTO – Compiler has to figure out 37 38 Subprograms Subprograms • AKA subroutine SUBROUTINE Name(formals) – User defined • When invoked …body… – Function returns a value – Using call stmt RETURN • Can be used in an expression END – Formals bound to • Important, late addition actuals • Why are they important? … – Formals aka dummy – Subprograms define procedural abstractions CALL Name (actuals) variables – Repeated code can be abstracted out, variables formalized – Allow large programs to be modularized • Humans can only remember a few things at a time (about 7) 39 40 Example Principles of Programming SUBROUTINE DIST (D, X, Y) • The Abstraction Principle D = X – Y IF (D .LT.