Advances in Language Design

Lecture 18:

Dolores Zage

Topics

Variations on Subprogram Control Parallel Programming Formal Properties of Languages Language Semantics Hardware Developments Software Architecture

Where do advances come from?

Formal models of the programming process experience->theory-> evaluation->

experience - programs have bugs, programming is hard theory -> structured programming, BNF grammars, data

abstractions evaluation -> build languages using these concepts

These have lead to further improvements object-oriented classes, SLR(1) and LALR(1)

parsing techniques

Von Neumann Architecture

Computer consists relatively large memory a much faster but smaller control memory CPU

All present languages implement these features

Changes in hardware and software architecture Machines increase by a factor of 2 every 3

years same basic problem remains -> control

memory and CPU are always about an order of magnitude faster than the larger main memory

a computer spends much time simply waiting

Waiting Problem Solutions

Software that allows for more efficient use of the hardware by concurrency

This permits the hardware to execute more efficiently by executing another program when one program is blocked waiting for data.

However, programmers are poor in rewriting applications to handle concurrency

Waiting Problem Solutions

Another solution is develop more effective hardware

More cache however the nature of computing of changing

-> client/server

Variations on Subprogram Control

Four assumptions on our usual activation record explicit call statements are required subprograms must execute completely at each

call immediate transfer of control at the point of call single execution sequence

Exception and Exception Handlers

Error conditions conditions detected by the virtual computer conditions generated by the semantics of the

programming language unpredictable conditions tracing and monitoring

Coroutines

Drop the assumption to allow subprograms to return to their calling program before completion of execution.

Two subprograms swapping control back and forth as each executes

now used in simulation languages

Scheduled Subprograms

Relax the concept that execution of a subprogram should always be initiated immediately upon its call

one way to think of a call is it is to be scheduled for execution immediately

can be thought of exception again used for discrete time simulation note no main, just a scheduler

Nonsequential Execution

Take away the assumption of single execution sequence

Parallel programming Concurrent programming

Parallel Programming

Multiprocessor system -> several CPUs Distributed or Parallel computer system has

several computers each with its own memory and CPU connected with communication links into a network

multiprogramming and time sharing major block - lack of support in PLs for the most part, languages use additional OS

calls

Parallel Programming Languages

Add complexity since several processors may be accessing the same data simultaneously

need 4 concepts Variable definitions - mutable or definitional Parallel composition - a statement to define

threads program structure - transformational or reactive communication - shared memory or messages

Commands of Concurrency

Construct to allow for parallel - the and statement 1 and statement 2 and … the statement beyond the and does not

execute until all the parallel statements finish guarded statements - nondeterministic

execution tasks - dependent semaphores ...

Formal Properties of Programming Languages Chomsky Hierarchy Undecidability Is there a limit to what we can compute with

a computer? Instead of writing a C program, can you write

another program that reads a description of the C program (its source file) and determines whether it would halt

Programming Verification

About the correctness and reliability languages are being designed with features

that enhance these attributes assert in C++

Hardware Developments

Improve the performance of a single CPU develop alternative architectures

Processor Design

CISC - making instructions more powerful, fewer instructions, less movement of data

RISC

System Design

Single bus crossbar switch Omega network

Software Architecture

Persistent or transient data read in persistent data into transient data

within the program and then rewrite the transient data back into the persistent storage

this type of model is inefficient for some systems

reservation system

Transaction System

Program executing continually reservations occur at any time just keep the data in transient problem of system going down and losing the

transient updates solve this by a persistent programming

language - no distinction between transient and persistent data

Networks and Client/Server Computing Major impact on programming language

design is the lack of a global data store for the program.

Both client and server only have limited access to the total information content of the program