Control constructs

1
Control constructs

• When writing high level code we need to be able
  to control whether to execute one set of
  instructions or some other set of instructions
  dependent upon some condition we will test
• To do this we have various control constructs e.g
  if else statements or while or for loops, etc
• In low level languages such constructs do not
  exist - the programmer has to use a more
  primitive mechanism to control the sequence in
  which the code is executed.
• The programmer takes responsibility for
  structuring the code to implement any control
  constructs

2
conditional branching

• The basic mechanism for controling the sequence
  of execution of instructions at the low level may
  be thought of as a 2-way choice where after the
  choice operation has executed, execution of the
  remaining instructions continues from one of 2
  different locations in your code dependent upon
  the result of a test applied to some value or
  values

3

• a choice operation has 2 components
• 1. A condition to test - this is a comparison
  between 2 values
• 2. Locations to continue execution from - in
  Oolong as in most assembly languages one of the
  locations is implicit, it is the location of the
  next instruction immediately following the
  conditional branch instruction, but the other
  location has to be specified explicitly using
  labels

4
Labels

• In Oolong locations of an instruction within the
  byte code may be specified by labels
• A label is an identifier followed by a colon, it
  occurs by itself on a line and at the start of a
  line
• The location labelled is the location of the
  instruction that immediately follows the label
  e.g.
• mylabel
• iconst_1 mylabel labels the instruction
  iconst_1
• bipush 20
• iadd

5
Byte code branches

• byte code conditional branches compare 2 values
  and are of 2 general types
• 1. compare an int or reference value with 0
• 2. compare 2 int or reference values with each
  other
• Branches can only jump to locations within a
  given method, attempting to jump to labels that
  exist in other methods is illegal
• The jump is implemented by replacing the value in
  the program counter (index into bytecode array)
  with index value represented by label

6

• the general format for 1. is
• ifcc ltlabelgt
• where the cc will vary depending on the condition
  being tested
• the value (int or reference) on top of the stack
  is popped off, it is compared to 0, and if the
  condition tested is true forces execution to
  continue from the location specified by the
  label, but otherwise the condition tested is
  false execution continues from the next
  instruction in the code after the branch
  instruction e.g.

7

• iload_1 put local var 1 onto stack
• ifeq mylabel if stacktop 0 then
• jump to mylabel
• otherwise continue with
• instruction following ifeq
• the order of comparison is always given by
• stacktop ltcomparison opgt 0

8

• The condition tested can be any of
• ifeq ltlabelgt branches to label if int 0
• ifne ltlabelgt branches to label if int ! 0
• ifgt ltlabelgt branches to label if int gt0
• ifge ltlabelgt branches to label if int gt0
• iflt ltlabelgt branches to label if int lt0
• ifle ltlabelgt branches to label if int lt0
• ifnull ltlabelgt branches to label if ref null
• ifnonull ltlabelgt branches to label if ref !
  null

9

• the general format for 2. is
• if_xcmpcc ltlabelgt
• where cc represents the condition being tested as
  before, and x represents the type of values being
  compared (i for int and a for reference)
• 2 values to be compared must be pushed onto stack
• the 2 values are popped off the stack and
  compared to each other, if the condition is true
  then execution continues from the location
  specified by the label, otherwise execution
  continues from the next instruction after the
  conditional branch instruction

10

• example
• iload_2 push local var 2 onto stack
• iconst_1 push constant int value 1 onto stack
• if_icmpne mylabel if local var 2 ! 1
• jump to mylabel
• the order of comparison is
• stacktop-1 ltcomparison opgt stacktop
• think of the order as being
• first value pushed ltcomparison opgt second value
  pushed

11

• The condition tested can be any of
• where stack is
• int1 lt---- top of stack
• int2
• if_icmpeq ltlabelgt branches if int2 int1
• if_icmpne ltlabelgt branches if int2 ! int1
• if_icmpgt ltlabelgt branches if int2 gt int1
• if_icmpge ltlabelgt branches if int2 gt int1
• if_icmplt ltlabelgt branches if int2 lt int1
• if_icmple ltlabelgt branches if int2 lt int1

12

• where stack is
• reference1 lt---- top of stack
• reference2
• if_acmpeq ltlabelgt branches if ref2 ref1
• if_acmpne ltlabelgt branches if ref2 ! ref1

13
If control construct

• The if control construct has the form
• if (conditional expression)
• if part statements
• note the branch, branches on condition tested is
  true, whereas high level construct proceeds on
  condition true

14

• general structure of an if control construct in
  byte code
• push values to be compared onto stack (1 or 2
  values depending)
• use ifcc or if_xcmpcc as appropriate with label
  that labels the code that follows code governed
  by condition (code after if part)
• then have code for if part statement block
• then label before first instruction of code
  following code in if part
• then rest of code

15
If example

• assume x is in local var slot 1
• and y in local var slot 3
• iload_1 push x
• ifne next if (x 0)
• iload_1 push x
• bipush 10 push 10
• iadd
• istore_3 y x 10
• next

• / JAVA VERSION /
• If (x 0)
• y x 10

16
If else control construct

• The if else control construct has the form
• if (conditional expression)
• if part statements
• else
• else part statements
• note again the sense of the branch - branching on
  true rather than proceeding

17

• general structure of an if else control construct
  in byte code
• push values to be compared onto stack (1 or 2
  values depending)
• use ifcc or if_xcmpcc as appropriate with label
  that labels code governed by else part
• then have code for if part
• then unconditional branch round else part code to
  label before rest of code following if else
  construct
• then else part label before first instruction of
  code for else part
• then code for else part
• then label for rest of code, then rest of code

18
unconditional branching

• The if else construct requires the use of an
  unconditional branch
• in unconditional branching no comparison between
  values is performed and the next instruction to
  be executed is simply specified by the label
• byte code instruction is
• goto ltlabelgt

19
If else example

• iload_2 push x
• iconst_1 push 1
• if_icmplt elselabel if (x gt 1)
• bipush 20 push 20
• iload_2 push x
• iadd
• istore_2 x x 20
• goto next skip to rest of code
• elselabel else
• iload_2 push x
• bipush 20 push 20
• isub
• istore_2 x x - 20
• next

• / JAVA VERSION - assume x an int at local var
  slot 2 /
• If (x gt 1)
• x x 20
• else
• x x - 20

20
The sense of conditionals in low level code

• if (x lt 10)
• if part statements
• in a high level language, in the above, the if
  part statements are executed when the condition
  evaluates to true (x lt10 is true)and jumps round
  them if condition false (x lt 10 is false), BUT
• The sense of the conditional branches in if and
  if else constructs for low level programs is
  generally inverse to that of the high level
  language

21

• using ifcc/if_xcmpcc if the condition tested by
  cc evaluates to true then it forces a branch
  (normally a branch round the following set of
  instructions) and on false it continues on to the
  following set of instructions e.g. code
  equivalent to HLL code above
• x is in local var 1
• iload_1 x on stack first
• bipush 10 10 on top
• if_icmpge next if x gt 10 then branch to next
• -if part instructions executed if xlt10
• next
• rest of code

22

• so at low level 3 alternatives either,
• 1. The conditional test used must be the inverse
  of that you might be thinking about if you are
  thinking about the algorithm for the problem
  using high level language ideas or
• 2. The conditional test may be the same, but the
  positions of the code governed by the if and the
  else parts must be swapped textually so that the
  else part code follows immediately after the if
  condition test and the if part instructions are
  the ones branched to

23

• 3. In java byte code it is also possible to
  reverse the order in which you push the operands
  onto the stack and then keep the normal sense of
  the conditional test e.g. with the if statement
  we have just been looking at we could
• bipush 10
• iload_1
• if_icmple branch if 10 lt x - which is the same
  thing as x gt 10
• Many other low level languages have a fixed order
  for comparing against constant values and so
  cannot reverse the comparison order like in 3.-
  it is best to stick with what is true for most
  languages

24

• Also ifcc instruction forces an order of
  comparison on you anyway which is the inverse of
  HLL approach
• In general it is less confusing to use 1. rather
  than 2 or 3. especially as your code becomes
  larger and more complex.
• With 1. The order in which the values are loaded
  matches the textual order of any high level
  algorithm, and the ordering of the code blocks in
  the low level code matches the textual order of
  any high level algorithm, the only issue is
  changing the sense of the comparison operator
  used.