1 / 47

Chapter 7: High-level Language Programming

Chapter 7: High-level Language Programming. Social Issues. Outline Where we are HLL Programming Software life cycle. Applications. Software. Virtual Machine. Hardware. Algorithmic Foundations. Where We Are. In the early 1950s: Writers of programs were very technical folks.

baris
Download Presentation

Chapter 7: High-level Language Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 7: High-level Language Programming Social Issues • Outline • Where we are • HLL Programming • Software life cycle Applications Software Virtual Machine Hardware Algorithmic Foundations

  2. Where We Are • In the early 1950s: • Writers of programs were very technical folks. • They had background in engineering, understood the internal functioning of computers. • They “wanted” to use assembly language in order to understand what the machine does under the hood. • They wanted to optimize their programs and the use of resources: • Example: LOAD X -- X R ADD ONE -- R+1 R STORE X -- R X … ONE: .DATA 1  Equivalent to: INCREMENT X -- X+1 X

  3. Where We Are • This “fine-tuning” of programs was easy at the assembly language level. • It saves few milliseconds to few seconds of processing time • Saving processing time was important since the machines were extremely slow • In later decades computers disseminated in society so that even the “nontechie” types needed to be able to write programs •  High-level languages were born • This was a mutual process: New programmers demanded better languages, which in their turn opened the way for new programmers • Also technological improvement made it possible to overcome the overhead of high-level language programming

  4. Where We Are • Consider adding two numbers (B and C, result is A): LOAD B -- B R ADD C -- C+R R STORE A -- R A … A: .DATA 0 B: .DATA 0 C: .DATA 0 • In order to perform such a simple operation (addition) we had to deal with data movement – from and to register R – for each number and for the result! •  More expressive instructions, like A = B + C, are highly desired • Recall each assembly language instruction corresponds to one machine language statement  assembly language is as expressive as machine language • Moreover, assembly language programs are machine-dependent

  5. Where We Are • Assembly language program that runs on machine X does not (necessarily) run on machine Y, due to the difference in data formats and instruction codes • Another problem is that even if the symbolic notation of assembly language is a good step forwards (compared with binary notation), there is still a gap between the language and the notation we usually use and that of the mnemonic notation • All in all, there are four major drawbacks of assembly language: • Data movement is done under program control • Programmers should have a microscopic view of their tasks • Assembly language programs are machine specific • No English-like statements are possible

  6. Where We Are • High-level language (HLL) were created to overcome these deficiencies: • Programmers need not to manage data movement • Programmers have a macroscopic view of tasks • Programs in HLL are potable (not machine specific) • Statements in a HLL are closer to standard English and usual notations • HLLs are often called third generation languages (machine language  assembly language  HLL)

  7. HLL Programming in LOGO • 1st Generation – Machine Language  had to type in all 0’s and 1’s  very hard and error prone • 2nd Generation – Assembly Language • Rather than 0’s and 1’s, uses op codes like Load, Add, • Store, etc • 3rd Generation – High level languages like BASIC, LOGO, COBOL, Pascal, C++

  8. HLL Programming in LOGO • HLL Programming languages (just like algorithms) have three main types of commands/operations/statements: • Sequential do something once • Conditional do something if a condition is true • Iterative keep doing something until some condition becomes false We will learn how to write programs using these types of statements in LOGO.

  9. HLL Programming in LOGO • Some features of LOGO • interactivity  user/programmer gets immediate feedback • modularity  huge programs can be well structured to cope with complexity • extensibility  programs are easy to extend • flexibility of data types  not strongly typed, which gives more flexibility for beginners, also programs can be changed easily.

  10. HLL Programming in LOGO Why LOGO? • is easy to learn. The syntax (i.e. the rules of writing) is fairly intuitive and the format is not too restrictive and fussy. • gives immediate visual feedback. You can see what you programmed immediately. • a “real” programming language. Although we will be using a small subset of commands that deal almost exclusively with drawing, do not get the impression that this is all LOGO can do.

  11. HLL Programming in LOGO • A subset of logo commands you will learn allow one to draw on the screen. • The commands control a turtle carrying a pen. • Positions on the screen are given by Cartesian coordinates. e.g. Center (origin) is (0,0) • The direction the turtle is facing is given by the number of degrees clockwise from facing the top of the page. I.e.: a right turn is a turn to the turtle’s right not the right side of the screen. • All commands are followed from the turtle’s point of view.

  12. HLL Programming in LOGO • Sequential Commands: Forward dist - fd dist - move the turtle dist pixels forward  Example: fd 20 moves turtle 20 pixels forward Backward dist - bk dist - move the turtle dist pixels backward  Example: bk 20 moves turtle 20 pixels backward Right degrees - rt deg - turn the turtle deg degrees to its right (clockwise)  Example: rt 45 turns turtle 45 degrees to its right Left degrees - lt deg - turn the turtle deg degrees to its left (counter-clockwise) • Example: lt 90 turns turtle 90 degrees to its left

  13. HLL Programming in LOGO • Sequential Commands: Setxy x y - move the turtle to position (x,y) direction faced will not change  Example: Setxy 10 10 turtle is moved to position (10, 10) Setx x - move the turtle to the right or left so that it’s new position is (x,?) direction faced will not change  Example: Setx 5 turtle is moved to position (5, y) Sety y - move the turtle to the up or down so that it’s new position is (?,y) direction faced will not change • Example: Sety 20 turtle is moved to position (x, 20) Setheading degrees - change the direction faced to degrees clockwise from facing the top of the screen, position will not change  Example: Setheading 180 turns turtle back

  14. HLL Programming in LOGO • Sequential Commands: Home – move turtle back to (0,0) direction 0 Clean – erase all drawing from the screen Showturtle – show the arrow mean to represent the turtle Hideturtle – hide the arrow mean to represent the turtle Penup – the turtle lifts the pen so that no drawing will appear when the turtle moves Pendown – the turtle puts the pen down so that drawing will appear when the turtle moves Wrap – change the way the turtle moves when it gets to the edge of the window it jumps to the opposite side of the window. Window - change the way the turtle moves when it gets to the edge of the window it keeps going into non visible space of the edge of the screen Fence - change the way the turtle moves when it gets to the edge of the window it stops and an error message is generated

  15. HLL Programming in LOGO • Example 1 : Draw a U graphics: fd 30 rt 90 fd 30 rt 90 fd 30 X turtle

  16. HLL Programming in LOGO • Example 2: A LOGO program that draws a square: Fd 100 Rt 90 Fd 100 Rt 90 Fd 100 Rt 90 Fd 100 Ht X

  17. HLL Programming in LOGO • Saving the program: • Put commands in a file called name.lgo • Before the first command put to name (for example: to mySquare) • After the last command put end • Load the program in the logo program then enter the name to run it. • You have created a procedure called name.

  18. HLL Programming in LOGO • The final program: To mySquare Fd 100 Rt 90 Fd 100 Rt 90 Fd 100 Rt 90 Fd 100 Ht end

  19. HLL Programming in LOGO • Conditional Statements: If condition [instruction list]  if then (no else) Ifelse condition [instruction list] [instruction list]  if then else Pendown? – true if the pen is down, false if it is up Shown? – true if the turtle is showing, false if it is hidden x = y or query = x – true if they’re equal x < y or query < x – true if the inequality is correct x > y or query > x – true if the inequality is correct Not (condition) – true if the condition is false And c1 c2 c3 … true only when all conditions are true Or c1 c2 c3 … false only when all conditions are false

  20. HLL Programming in LOGO • Queries: Queries are commands that give you information: Pendown? and Shown? Are both queries. Xcor - Outputs a number, the turtle's X coordinate. Ycor - Outputs a number, the turtle's Y coordinate. Heading - Outputs an angle, the turtle's heading in degrees. Angle going clockwise from top of the page. Towards - Outputs an angle, the heading in degrees, at which the turtle should be headed so that it would point from its current position towards the position given as the argument. Distance - Outputs a number, the distance the turtle must travel along a straight line to reach the position given as the argument.

  21. HLL Programming in LOGO • Example: Draw a shape To drawShape ifelse heading = 0 [mySquare] [fd 200 rt 90 fd 100 rt 90 fd 200 rt 90 fd 100 ht] end Draws a square if the heading is 0 otherwise it draws a rectangle In the real program the entire ifelse command must appear on one line

  22. HLL Programming in LOGO • Iterative commands: Loops do a set of steps repeatedly. • Repeat (number) [(instruction list)] This is a counting loop, it does all the steps in the instruction list “number” times, you can use the repcount query to determine which number time through the loop you are at, the counting starts at zero and goes up to and includes the given value for number. • While (condition) [(instruction list)] Does all the instructions in the list repeatedly until the condition becomes false. This is a “true” loop and may therefore lead to an endless loop, if condition never becomes false. (There are many other types of loops in LOGO)

  23. HLL Programming in LOGO • Main data types: Numbers: A combination of digits and potentially some further symbols for the representation of negative and floating point numbers Examples: 1 2435 -13 4.6 -3.15E10 Words: A combination of letters and digits that begins with a quote. Examples: “adam “OTTO “item14

  24. HLL Programming in LOGO • Main data types (continued): Lists: An ordered sequence of objects enclosed in brackets. In particular, a list may include other lists as elements. Examples: [adam OTTO item14] [[adam 1] [OTTO 30]] [] (empty list)

  25. HLL Programming in LOGO • Simple functions: Arithmetic operations: Examples: SUM 2 4  6 2*4  8 List operations: FIRST: Get the first element of a list. BUTFIRST: Get the list without the first element. Examples: FIRST [adam OTTO item14]  adam FIRST [[adam 1] [OTTO 30]]  [adam 1] BUTFIRST [adam OTTO item14]  [OTTO item14]

  26. HLL Programming in LOGO • Variables: A variable is a named placeholder for some value.  Definition of a variable called number: MAKE “number 20  Get the value stored in the variable using THING: THING “number  20 Example: The following commands print the value 25 on the screen: MAKE “number 20 MAKE “result SUM THING “number 5 PRINT THING “result

  27. HLL Programming in LOGO • Definition of functions/procedures: Function: A named part of a program that returns a result. Procedure: A named part of a program that does not return a result. • Example for a function in LOGO: to second :list output FIRST BUTFIRST :list end  :list is a parameter for the function named second  output is a command for returning a result  This function returns the second element of a list

  28. HLL Programming in LOGO • Example for the use of function second: second [adam OTTO item14]  OTTO second [adam [OTTO item14]]  [OTTO item14] • :list is a parameter and may vary Do not forget the “:” Meaning of “:” is “value of” • Another Example: to length :list If EQUALP :list [] [output 0] [output 1 + length BUTFIRST :list] end

  29. HLL Programming in LOGO • Our new function has the name length. • It uses the EQUALP to test the equality. • The function computes and returns the length of a given list. • It checks first whether or not the list is empty, if so 0 is returned. • If the list is not empty, it proceeds with calculating the length of the list without the first element and adds 1 to the returned value. • Examples for the use of length: length [adam OTTO item14]  3 length []  0 length [adam [OTTO item14]]  2

  30. HLL Programming in LOGO • Functions and procedures can be nested:  A function/procedure can call another function/procedure  A function/procedure can call itself (see function length) • Example: The following procedure draws a V to V lt 45 fd 20 bk 20 rt 90 fd 20 bk 20 lt 45 end

  31. HLL Programming in LOGO • The following procedure draws a branch and uses the procedure V: to branch fd 30 V fd 30 V fd 15 bk 75 end

  32. HLL Programming in LOGO • The following procedure draws a scrub and uses the procedure branch: to scrub left 80 repeat 7 [right 20 branch] left 60 end

  33. Program Translation • HLL price is that we need a translator • Unlike the Assembler, which translates from assembly to machine language, we now need a compiler that translates from HLL, for example, LOGO to machine language • In fact the compiler can also translate from HLL to assembly language, and the Assembler can be used for further translation to machine language • Compiler • More complicated than an Assembler • No 1-to-1 relationship between HLL instruction and machine level ones as in assembly language! • In order to use LOGO on a computer, the computer should have a LOGO compiler • In fact, one needs a compiler for each pair of (HLL, machine) • For example: LOGO compilers/interpreters for IBM PCs, for VAX machines, for Macs, etc.

  34. Sample Translation Steps Intermediate Assembly Language Code Program e.g. branch Compiler interpreter Assembler Results Object code in memory Object Code (in a file) Hardware Loader

  35. Modularity (Or Top-Down Design) • Suppose you (perhaps with others) are asked to write a program that was estimated to have 100,000 lines !!! • Spontaneous questions: • How to begin? • Where to begin? • How can I understand what I programmed 6 months ago? • How can I understand code that others (working with me) wrote? • Main principle: divide and conquer • Divide your complex problem into distinct parts, called modules, which are manageable and compact • Top down: begin with most abstract module first • Bottom up: begin with most concrete module first

  36. How LOGO Supports Modules • Two types of modules in LOGO: procedures and functions • For example, the scrub program has been divided into 3 modules: • V • branch • scrub • In general top down design is preferred:  this means begin with scrub in our example and not with V (what we did is bottom up design)  If module 1 uses modules 1.2 … 1.N then begin with module 1

  37. Software Life Cycle • Main phases: • Feasibility Study • Problem Specification • Program Design • Development and analysis • Coding • Debugging • Testing/Verification and Benchmarking • Documentation • Maintenance

  38. Software Life Cycle • Feasibility study • Is a software solution worth for user? • Perhaps it is better not automate… • Cost estimates for e.g. • Machines including I/O (e.g. printers) • Software packages • Salaries for developers • Training costs for users •  Costs often higher than expected! • Result: Feasibility document that recommends whether or not to start project

  39. Software Life Cycle • Problem specification (The What): • Clear, concise, and unambiguous statement of the exact problem to be solved is needed • Original specification (used in feasibility study) is usually in natural language (e.g. English) and often comprises unclear, incomplete, or even contradictory statements • Thus, software designers (computer scientist) and user (?) need to hammer out any gap or inconsistency in the problem statement • Why? •  Changes are easier in this phase than in later ones (e.g. after program is developed) •  It is like changing your mind when looking at the blueprints of your new home rather than after the foundation has been dug and the walls have started to go up!

  40. Software Life Cycle • Result of problem specification is a document specifying exactly how the program will behave in all circumstances (also under unusual conditions). Examples are expected data input, computed results, ways of how results are displayed… • Program design (The How) • Divide and conquer: e.g 100, 000 lines = 1000 x 100 lines • Thus, problem is subdivided in modules of small size • Each module needs to be specified: • What does the module do? • What information is needed from other modules? (input) • What information is provided to other modules? (output) • Module specification should be sufficiently detailed that a programmer could immediately write program using it. • This phase is the most creative phase; compare designing an airplane to riveting its wing!

  41. Software Life Cycle • Algorithm selection (or development) and analysis • For each specified module an algorithm should be identified to carry out it functionality • Example: A module may be assigned the task of searching some particular number in a list of numbers •  What algorithms are convenient (e.g. sequential or binary search) • Also, it may be the case that a new algorithm has to be developed, also a very creative task. • The documentation of this phase includes the description of used algorithms (in e.g. pseudo-code) and rationales for their use. • Coding (sometimes also called development) ( e.g. in Pascal, C, … ) • Each module is to be written in a programming language (which one?  is part of early decisions in the feasibility study) • Coding is a relatively routine job, reusable code can be also used • This step usually comes to mind when people think of software, but in fact this step is preceded by more important ones that facilitate it • Result of the coding is a document, namely, the code itself with comments and description of implementation decisions

  42. Software Life Cycle • Debugging • This is the process of finding and removing program errors • Can be very time-consuming (even more than coding time) • Types of errors: • Syntax errors • Violation of the rules of form (syntax) in the respective programming language • Detected by the compiler • Examples:  missing names  semicolon is missing  curly brace is missing  no semicolon is needed

  43. Software Life Cycle • Run-time errors • Occur when program is running using certain data that result in an illegal operation • E.g. dividing by zero • System software can help detect this kind of errors • Logic errors • The program compiles well and runs well but does not produce the expected results. • Problem may be in coding the module, in the algorithm of the module, or even a step earlier in the development process • No tools that help pinpoint this problem • Poorly done design results in a structural mess with convoluted and hard-to-understand logic • Documentation of debugging process includes notes on found problems and how code was changed to solve them, this prevents later changes from re-introducing older errors.

  44. Software Life Cycle • Testing, verification, and benchmarking • Even though the program produces correct answers for 1, 5, or even 1000 data sets, how can we be sure that it is indeed 100% correct? • Three methods can help • Empirical Testing: • Design a special set of test cases and run the program using them • Test data that is carefully chosen to exercise all different logic paths of a program can help uncover errors • For example: if(a = b) then a = a+1 else b = b+1;  Data set {(1, 1), (1, 0)} let the condition be true and false thus executing the two possible paths • Problem: data sets that cover ALL paths are in most cases unfeasible

  45. Software Life Cycle • Program verification • Rigorous mathematical proof that the program will produce the correct results when certain conditions are satisfied •  Good for small modules (perhaps critical ones) •  Bad in general since programs tend to be very complex and large • Hence, testing is used more often than verification in practice • Benchmarking • Addresses primarily efficiency and not reliability • Run program on many different data sets to be sure that performance requirements are met (e.g. amount of computation time) • At the end of this phase  Program should produce: a) correct results (e.g. thoroughly tested) b) within the prescribed performance limits (e.g. well-benchmarked)

  46. Software Life Cycle • Documentation • Written material that makes program understandable and useable • Internal documentation: • Part of the code; meaningful names, comments, modules • External documentation: • Accompanying each step of the software life cycle • Final documentation • Technical documentation • For programmers that may modify the program • User documentation • For users that use the program (how to run it, on-line tutorial …)

  47. Software Life Cycle • Maintenance • Software is used for a very long time • Maybe longer than ever expected  Year 2k Problem • A medium-to-large software cycle may include 2 to 3 years of development (from feasibility to testing) and 5 to 15 years in the marketplace • During this long period of use some new needs can arise: • New errors may be uncovered • User preferences may change • New hardware may be used • The whims of the marketplace fluctuate •  Original program has to be modified • Maintenance is the process of adapting an existing software product due to any of above reasons. • Maintenance is not a genuine separate step in the software life cycle, since it mainly involves repetitions of other phases.

More Related