Chapter 7: High-level Language
Programming
Social Issues

Outline
Applications
Software



Where we are
HLL Programming
Software life cycle
Virtual Machine
Hardware
Algorithmic Foundations
1
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
2
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
3
Where We Are

Consider adding two numbers (B and C, result is A):
A:
B:
C:




LOAD
ADD
STORE
…
.DATA
.DATA
.DATA
B
C
A
-- B R
-- C+R R
-- R A
0
0
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
4
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
5
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)
6
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++
7
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.
8
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. 9
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.
10
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.
11
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 (counterclockwise)
 Example: lt 90 turns turtle 90 degrees to its left
12
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
13
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
14
stops and an error message is generated
HLL Programming in LOGO
• Example 1 : Draw a U graphics:
fd 30
rt 90
fd 30
rt 90
fd 30
X
turtle
15
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
16
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.
17
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
18
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
19
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.
20
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
21
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)
22
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
23
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)
24
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]
25
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
26
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
27
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
28
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
29
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
30
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
31
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
32
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.
33
Sample Translation Steps
Program
e.g. branch
Compiler
interpreter
Intermediate
Assembly
Language
Code
Assembler
Results
Hardware
Object
code in
memory
Loader
Object Code
(in a file)
34
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
35
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
36
Software Life Cycle

Main phases:









Feasibility Study
Problem Specification
Program Design
Development and analysis
Coding
Debugging
Testing/Verification and Benchmarking
Documentation
Maintenance
37
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
38
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!
39
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!
40
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
41
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
42
Software Life Cycle

Run-time errors




Logic 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
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 hardto-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.
43
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
44
Software Life Cycle

Program verification





Benchmarking



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
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)
45
Software Life Cycle

Documentation
 Written material that makes program understandable and
useable
 Internal documentation:


External documentation:


Part of the code; meaningful names, comments, modules
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 …)
46
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.
47