Chapter 7: Highlevel Language Programming

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 -- R1? R
• STORE X -- R? X
• ONE .DATA 1
• ? Equivalent to
• INCREMENT X -- X1? 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 -- CR? 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 0s and 1s
• ? very hard and error prone
• 2nd Generation Assembly Language
• Rather than 0s and 1s, 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/state
  ments
• 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
  turtles right not the right side of the
  screen.
• All commands are followed from the turtles 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 its 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 its 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 theyre equal
• x lt y or query lt x true if the inequality is
  correct
• x gt y or query gt 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
• 24 ? 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 a1
• else
• b b1
• ? 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.