CSECE 365 Computer Architecture

1
CS/ECE 365 Computer Architecture

• Soundararajan Ezekiel
• Department of Computer Science
• Ohio Northern University

2
Compilers and Computer Architecture

• Relation between Architecture and Compiler design
  
• Leads to several principles which can simplify
  compilers and improve the object code they produce

3
Introduction

• Interaction between COMPUTER INSTRUCTION SET and
  DESIGN OF COMPILERS that generates code for that
  computer have serious implication for overall
  computational cost and efficiency
• In this Lecture we will investigate those
  interactions

4
Begin

• Observe that hardware cost falling rapidly
• cost of software is rising
• The inevitable conclusion is we ought to find
  ways for the hardware to simplify the software
  task
• One area this might be done is
• Design of instruction sets that better reflect
  the needs of high-level languages

5
Continue

• Better instruction sets would both simplify
  compilers and improve the size and the speed of
  the programs they generate
• This observation is absolutely correct
• Many people think that efficiency of object code
  from a compiler is no longer important----This is
  FASLE
• Let me illustrate with example

6
Example

• Today I use a timesharing system that is 10 times
  faster than the one I used a decade ago
• 8-10 times more primary memory--vast secondary
  memory
• Yet it support the same number of people, and the
  response is WORSE
• Reason Our aspiration is grown much faster than
  technology has been able to satisfy them

7
Continue

• It now takes more cycles, more memory, more disk,
  ,,more everything.---to do what a typical user
  wants expect
• I believe this is good--despite its degraded
  performance, the system is more responsive to my
  overall needs
• Although hardware costs continue to fall
  dramatically and machine speed increase
  simultaneously---- our aspiration will rise even
  more

8
continue

• given any system, people will want to improve it
  and make it more responsive, inefficiencies that
  thwart those aspirations will not be tolerated
• Before discussing the mutual impact of compilers
  and target machine architecture, we need to
  clarify the objectives of the exercise

9
The cost equation

• the number of costs and conversely benefits, are
  involved. They include
• designing(writing)compilers
• designing hardware architecture
• designing the hardware implementation of that
  architecture
• manufacturing the hardware(replicating the
  implementations)
• executing compilers and
• executing the compiled programs

10
First

• the relative importance of these costs is, of
  course, installations--and application-dependent-o
  ne cannot make statements about their relative
  importance without more specific information
• first
• Note that only the 4th item has decreased
  dramatically
• Designing irregular structure at the chip level
  is very expensive

11
Second

• Second, all of the design activities (compilers,
  architectures, and implementations) are one time
  costs
• From the customer s perspective, --- number of
  unit sold

12
Third

• Both software and architecture have life
  substantially longer than that of hardware
  technology for which they are initially
  implemented.

13
Finally,

• the last two items, executing compilers and
  executing the compiled programs-- are not
  strictly comparable to those preceding them--
• dollar costs can be assigned to these, of course.
• However the correct measure is not in terms of
  dollars but in terms of things that cannot be
  done as a consequences of compilation or
  execution inefficiencies

14
conclusion

• Hence, inefficiencies in compilation and
  execution manifest themselves as decreased
  productivity, unavailable functionality, and
  similar costs.

15
Some general principles

• Principles that would improve the impedance match
  between compilers and a target computer
  architecture
• Regularity
• Orthogonality
• Composability

16
Regularity

• If something is done in one way in place , It
  ought to be done in the same way every where
• This principle is called the law of least
  astonishment in the language design community

17
Orthogonality

• It should be possible to divide the machine
  definition or language definition into a set of
  separate concerns and define each in isolation
  from the others
• Example possible to discuss data type,
  addressing, and instructions set independently

18
Composability

• If the principles of regularity or Orhogonality
  have been followed,then it should also be
  possible to compose the above principles in an
  arbitrary way

19
Comments

• However, these principles have not been
  completely followed
• Let me comment the above principles although
  many compiler optimization are cast in terms of
  esoteric-sounding operations such as flow
  analysis and algebraic simplification, these case
  are aimed to perform enormous case analysis.
• Objective determine the best object code for the
  given source program

20
Additional, more specific principles

• One vs all There should be precisely one way
  to do something or all ways should be possible
• Provide Primitives not solutions It is far
  better to provide good primitives from which
  solutions to code generation problems can be
  synthesized than to provide the solutions
  themselves

21
Example for one vs all

• only conditional branching instructions are ones
  that test for EQUALITY and LESS THAN, there is
  only one way to generate code for each of the six
  relations.
• Alternatively, if there is a direct
  implementation of all six relations, there is an
  obvious coding for each.
• Difficulties arise , however, if only 3 or 4 of
  the six are provided

22
Example

• some modern architecture have provided direct
  implementations of of high-level concept such as
  FOR and CASE statements and PROCEDURE calls
• In many cases these turn out to be more trouble
  than they are worth---they are inefficient for
  special case
• it is semantic clash between language and and
  high level instruction

23
Final 3 principles

• Addressing Address computations are path!
• is not limited to simple array and record access!
• the addresssing modes of a machine should be
  designed to recognize these facts

24
Environment support

• All modern Architecture supports arithmetic and
  logical computations reasonably well
• they do not do nearly as well in supporting the
  run-time environments for programs--stack frames,
  display,. exceptions, processes and so on
• the writer should provide such run-time support

25
Deviations

• The writer should deviate from these principles
  only in ways that the implementation independent
• Note In my experience, effective use of
  implicit addressing is the most important aspect
  of generating good code

26
Kudos and gripes

• From the compiler perspective, various machines
  have both good and bad features which
  illustrate--or violate--the principles discussed
  above
• On Regularity
• Most machine support several data type(including
  fixed or floating point forms)
• several types of words(essentially boolean
  vectors)
• several types of addresses
• it is rare for operators on these types to be
  defined regularly

27
continue

• conditions codes that are not set in the same
  way
• carries that do not propagate beyond the size of
  an address
• operations that are restricted to operate on a
  selected se of index registers

28
continue

• On Orthogonality ability to define separate
  concerns-- such as addressing, operations and
  data types--separately
• on composability for example The ADD instruction
  should have identical effects whether is add
  literals, bytes or words

29
Examples

• consider simple statement ABC
• suppose we are compiling for a machine on which
  the operand of a multiply must be an odd
  register.---simple compilers generally allocate
  registers on the fly as it generates code.
• In this example, such strategy appears work well

30
continue

• consider A(BD)C, strategy breaks down
• Addition can be done in either an even or odd
  registers
• a simple on the fly allocations is as likely to
  get en even registers as an odd one for BD
• the choice of an even one will necessitate an
  extra data move to implement the multiplication
  by C

31
Continue

• more ambitious compilers must there fore analyze
  a complete expression tree before making any
  allocations.
• in trees involving conflicting requirements, an
  assignment must be found that min data movement

32
On one vs all

• many of you know examples of this violations
• Favorite in the newest machine-- one with
  generally excellent instruction set
• This set includes reasonably complete boolean
  operations, but does not provide AND , instead
  providing only AND NOT .
• AND is commutative and associative but AND NOT is
  not
• we have to determine which operand to complement
  and when to apply DeMorgans law to generate
  optical code sequence

33
On primitives vs solutions

• most people argues Pascal is more powerful than
  Fortran
• most powerful is not clear
• any algorithm can be coded in in Fortran can also
  be coded in Pascal-but not conversely
• COMMON, EQUIVALENCE are not present in Pascal
• there is semantic clash between the languages

34
Machine that attempt to support all the mechanism
probably fail to support all the requirements

• subroutine call instructions that support, ex
  only some parameter passing mechanism
• looping instructions that support only certain
  models of initialization, test and increment and
  recomputations
• addressing modes that presume certain stack frame
  layouts- or even presumes particular
  representations of arrays
• case instructions that only do or dont
  implicitly test the boundary conditions of the
  case index and only do dont assume such bounds
  are static at compile time

35
continue

• instructions that support high-level data
  structure ( such as queues) and make assumptions
  that differs from some common implementations of
  these structure
• elaborate string manipulations

36
On addressing

• Modern programming languages permit the
  definition of data structure that are arbitrary
  compositions of scalars, arrays, records, and
  pointers.
• In principle it is possible to define an array of
  records, a component of which is a pointer to a
  record containing an array of arrays of yet
  another kind of record.

37
Continue

• Accessing a component at the bottom level of this
  structure involves a lengthy sequence of
  operations
• Because the interaction among the block
  structure, recursive procedures,and by reference
  parameters passing, finding the base address of
  such address can equally complex,

38
On environments

• I believe that most people now appreciate
  hardware support for recursive procedure
  invocation, dynamic storage allocation and
  synchronization and communications process.
• I just want to point out some area s
• Uninitialized variables
• Constraint Check
• Exceptions
• Debugging support

39
Conclusion

• Above all, In many cases I have examined, the
  code produced for such an interpreter is roughly
  two times slower and larger than it needs to be
• Both the compiler writer and the machine designer
  have multiple objectives.
• The machine designer should certainly attend to
  the concerns of high-level-language
  implementation-since most programs will be
  written in one

40
Continue

• consider cost, reliability, compatibility,
  customer acceptance and so on
• faithfully implement semantics of the source
  language
• must provide a friendly interface to the users
• try to reach reasonable compromise between the
  speed of compilation and the quality of resulting
  object code

41
Finally

• we all know that you can still do a great deal to
  improve the match between languages and machines
  and so reduce total costs

42
Homework

• The Microprocessor Today
• (or)
• The Future of Microprocessor
• Look for Hint and useful information in course
  page